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I.  YEAR  2000  PROBLEM 


A.  DESCRIPTION  OF  YEAR  2000  PROBLEM 

As  we  approach  the  most  anticipated  new  year  of  our  lifetime,  the  Millennium, 
something  else  is  looming  on  the  horizon  “The  Year  2000  Problem”. 

A  June  2, 1997,  Newsweek  article  titled  “The  Day  the  World  Crashes”, 
writes  Drink  deep  from  your  champagne  glasses  as  the  ball  drops  in  Times  Square 
to  usher  in  the  year  2000.  Whether  you  imbibe  or  not,  the  hangover  may  begin 
immediately.  The  power  may  go  out.  Or  the  credit  card  you  pull  out  to  pay  for 
dinner  may  no  longer  be  valid.  If  you  try  an  ATM  to  get  cash,  that  may  not  work, 
either.  Or  the  elevator  that  took  you  to  the  party  ballroom  may  be  stuck  on  the 
ground  floor.  Or  the  parking  garage  you  drove  into  earlier  in  the  evening  may 
charge  you  more  than  your  yearly  salary.  Or  your  car  might  not  start.  Or  the  traffic 
lights  might  be  on  the  blink.  Or,  when  you  get  home,  the  phones  may  not  work. 
The  mail  may  show  up,  but  your  magazine  subscriptions  will  have  stopped,  your 
government  check  may  not  arrive,  your  insurance  policies  may  have  expired.  Or 
you  may  be  out  of  a  job.  When  you  show  up  for  work  after  the  holiday,  the  factory 
or  office  building  might  be  locked  up,  with  a  handwritten  sign  taped  to  the  wall: 
Out  of  Business  due  to  computer  error.  Could  it  really  happen?  Could  the  most 
anticipated  New  Year’s  Eve  party  in  our  lifetimes  really  usher  in  a  digital 
nightmare  when  our  computer  dependent  civilization  grinds  to  a  halt?  Incredibly, 
according  to  computer  experts,  corporate  information  officers,  congressional 
leaders  and  basically  anyone  who’s  given  the  matter  a  fair  hearing,  the  answer  is 
yes!  Yes,  unless  we  successfully  complete  the  most  ambitious  and  costly 
technology  project  in  history,  one  where  the  payoff  comes  not  in  amassing  riches 
or  extending  Web  access,  but  securing  raw  survival.  What  is  the  problem?  It’s 
called,  variously,  the  Year  2000  Problem,  Y2K  or  the  Millennium  Bug.  [Ref.  1] 

The  Year  2000  Problem  is  receiving  increasing  attention  throughout  the  world.  It 
is  going  to  affect  everyone  and  its  deadline  is  will  not  change. 

According  to  Kevin  Schick  of  the  Gartner  Group  [Ref.  2],  The  year  2000 
is  not  rocket  science,  but  it  is  the  largest  project  ever  to  be  undertaken  by  the  IT 
organization.  The  complexity  of  the  project  is  not  in  the  solution  but  rather  in  the 
size  and  scope  of  the  project  itself . 

Melvin  Scott  of  Boeing  Information  Services  and  Philip  H.  Newcomb  of 
The  Software  Revolution,  Inc.  write  Although  the  government  has  gone  through 
extensive  software  changes,  because  of  its  pervasiveness,  the  Y2K  problem  is 
arguably  of  unprecedented  scope  and  complexity.  It  involves  a  multitude  of 
dependencies  between  software,  hardware,  databases,  systems,  interfaces, 
businesses,  and  regulatory  relationships  that  involve  coordination  between 
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multiple  organizations,  enterprises,  agencies,  and  thousands  of  software  package 
and  database  suppliers.  [Ref.  3] 

Ed  Yourdon’s  introduction  to  the  February  1996  issue  of  American 
Programmer  states,  For  nearly  20  years.  I’ve  been  joking  to  my  professional 
colleagues,  and  to  my  non-technical  friends  outside  the  industry,  that  in  1999 1 
plan  to  sell  all  my  earthly  belongings  and  move  to  a  small  island  in  the  Pacific,  in 
the  hope  that  it  will  be  a  safe  haven  during  the  chaos  surrounding  the  so-called 
“century  date  change.”  [Ref.  4] 

Given  this,  its  easy  to  understand  why  many  are  referring  to  the  Year  2000 
problem  as  the  single  largest  computer  effort  ever. 

Capers  Jones  states  [Ref.  5],  “The  Year  2000  problem  will  be  one  of  the 
most  expensive  problems  in  human  history.” 

The  Gartner  Group  estimates  that  the  cost  to  correct  the  problem  worldwide  could 
run  between  $300  -  $600  billion  dollars.  Where  is  all  this  money  going  to  come  from  to 
fix  these  systems?  For  commercial  companies,  the  money  will  come  from  an  increase  in 
the  cost  of  goods  and  services.  For  the  government,  the  money  will  come  from  increased 
tax  revenues,  or  postponed  or  canceled  services.  Many  companies  may  suffer  financially 
and  this  will  impact  the  worldwide  economy.  In  addition,  the  longer  an  organization 
waits,  the  more  it  will  cost,  because  consulting  rates  to  help  solve  the  problem  are 
currently  increasing  as  the  demand  for  this  support  continues  to  increase.  Organizations 
will  need  to  evaluate  their  Year  2000  budgets  and  refine  these  as  they  proceed  through  the 
Year  2000  effort. 


Peter  de  Jager  in  his  web  article  “You've  got  to  be  Kidding!”  explains  in  a 
very  simplistic  way  how  and  why  this  situation  happened.  He  states  we 
programmed  computers  to  store  the  date  in  the  following  format  dd/mm/yy.  This 
means  that  we’ve  allowed  2  digits  for  the  day  (dd),  2  digits  for  the  month  (mm) 
and  only  2  digits  for  the  year  (yy).  Some  examples  might  help.  If  you  were  bom 
on  June  2,  1952,  that  information  would  be  stored  in  the  computer  as  06/02/52. 
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January  1st  2000  will  be  stored  in  the  computer  as  01/01/00.  We’ve  told  the 
computer  to  assume  that  06/02/52  means  06/02/1952.  What  will  it  assume 
01/01/00  means?  It  will  assume  that  01/01/00  means  01/01/1900  or  January  1st 
1900.  And  that  is  the  problem.  Many  computers  will  think  that  all  dates  past 
December  31st  1999  are  100  years  in  the  past.  To  understand  the  implications  of 
this  error,  we  must  look  at  one  of  the  most  basic,  and  most  common,  calculations 
performed  by  the  computer:  the  calculation  that  determines  how  much  time  has 
passed  from  one  event  to  the  next.  For  example,  how  old  are  you?  I  was  bom  on 
June  2, 1952.  If  I  ask  the  computer  how  old  I  am,  it  subtracts  my  birth  date  from 
the  current  date.  It  will  perform  a  calculation  similar  to  97-52  (remember  it  only 
has  2  digits  for  the  year  information)  and  gives  the  answer  of  45  years  old,  which, 
while  unfortunate,  is  also  true!  On  January  1st  2000,  the  calculation  will  be 
exactly  the  same.  Subtract  my  birth  year  from  the  current  year,  00-52  and  the 
computer  will  proclaim  that  I’m  -52  years  old,  which  is  obviously  incorrect.  This 
will  cause  havoc  with  every  similar  calculation  in  every  program  in  every 
company  in  every  country,  worldwide.  It  affects  more  than  just  age  calculations.  It 
affects  all  information  based  on  time.  When  will  your  driver’s  license  expire? 
When  will  your  credit  card  expire?  When  will  this  drag  no  longer  be  safe?  When 
should  this  machine  undergo  regular  maintenance?  When  was  this  product  built? 
How  long  has  this  invoice  been  overdue?  Has  this  subscription  expired?  All  of 
these  calculations  are  based  on  the  date,  and  if  the  computer  does  not  know  what 
date  it  is,  then  these  calculations  are  no  longer  possible...  Why  did  we  use  only  2 
digits  when  we  knew  we’d  need  4  digits  when  the  Year  2000  rolled  around?  It 
was  done  deliberately,  but  with  the  very  best  of  intentions.  When  computers  first 
entered  the  business  world  in  the  late  1960s  and  the  early  1970s,  they  were  very 
expensive.  This  expense  was  tied  directly  to  two  aspects  of  computing,  how  much 
data  could  the  computer  store  and  how  fast  could  it  process  that  data.  Even  tiny, 
incremental  increases  in  either  attribute  resulted  in  huge  cost  increases.  One  way 
to  store  data,  was  on  a  piece  of  stiff  cardboard  known  as  a  Hollerith  card.  By 
literally  punching  holes  into  this  Hollerith  card  according  to  a  set  of  patterns,  and 
reading  those  patterns  with  a  beam  of  light,  one  could  store  and  retrieve 
information.  Each  of  these  cards  had  enough  space  to  hold  only  80  characters  of 
information.  Eighty  characters  is  not  a  lot  of  information...  So  (programmers) 
compromised.  They  wrote  230155  instead  of  23/01/1955,  thereby  saving 
themselves  4  precious  characters,  2  of  which  were  the  crucial  '19'.  When 
designing  a  computer  application,  compromises  are  always  made  such  as  between 
what  is  desirable  and  what  is  affordable  and  between  the  speed  of  delivery  and  the 
quality  of  the  final  product.  Hopefully,  the  consequences  of  the  compromise  are 
understood  and  accepted  ahead  of  time,  because  compromises  are  never  perfect 
solutions.  We  compromised  on  accuracy  vs.  cost  when  we  decided  to  store  only  2 
digits  of  the  year.  The  reasoning  to  do  so,  even  now,  makes  a  lot  of  sense, 
especially  if  the  era  in  which  this  happened  is  kept  in  mind...  the  year  2000  was 
30  or  40  years  away.  Part  of  the  reasoning  was  that  surely  the  code  would  be 
replaced  by  then.. .That  particular  assumption  has  proven  to  be  very  wrong,  as 
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evidenced  by  the  large  quantity  of  old  code,  known  as  Legacy  Systems,  in  use 
today... It  seemed  a  very  reasonable  compromise  to  make  at  the  time.  And 
compromises  are  never  made  in  isolation,  compromises  are  always  a  conspiracy 
or  collaboration.  Computer  managers  would  tell  the  client  that  if  they  stored  all  4 
digits  they’d  have  to  buy  a  bigger  computer  or  they’d  have  to  write  a  much  more 
complicated  program  to  store  the  data  on  2  or  3  or  4  Hollerith  cards.  The  client 
would  typically  respond  ‘You  want  me  to  spend  another  million  dollars  to  store 
an  extra  2  digits  that  won’t  even  be  used  for  30  years!  In  fact,  why  not  store  a 
single  digit  and  save  even  more  money?’  So,  this  compromise  became  an  industry 
standard.  [Ref.  6] 


The  MITRE  Corporation  is  a  Federally  Funded  Research  and  Development 
Corporation  (FFRDC)  tasked  by  many  agencies  within  the  federal  government  to  support 
these  agencies  in  understanding  and  solving  their  Y2K  problems. 


The  description  of  the  Y2K  problem  is  explained  on  their  Y2K  Home 
Page  Unfortunately,  the  problem  is  not  isolated  to  programming  errors  caused  by 
the  use  of  the  two-digit  year  coding  scheme.  The  year  2000  presents  a  triple 
witching  hour  of  potential  traps  for  designers  and  programmers.  In  addition  to  the 
two-digit  year  coding,  there  are  distinct  issues  surrounding  the  use  of  the  six-digit 
date  representation,  and  still  other  risks  caused  by  the  calculation  of  the  leap  year. 
And  just  to  make  matters  worse,  January  1,  2000  falls  on  a  Saturday.  Problems 
caused  by  coding  errors  may  not  be  discovered  until  the  next  regular  working  day, 
allowing  enough  time  for  the  errors  to  inflict  a  great  deal  of  damage.  [Ref.  4] 
They  continue  by  defining  the  Y2K  problem  as  involving  any  or  all  of  the 
following  instances: 

•  Two-Digit  Year  Coding,  use  of  two  digits  to  represent  the  year,  is  expected  to 
be  the  most  common  cause  of  year  2000  failure.  Applications  that  require  the 
user  to  enter  a  date  routinely  present  a  two-digit  field  to  the  operator  in  an 
attempt  to  reduce  the  number  of  keystrokes  needed  to  enter  data.  Failure  to 
append  the  correct  century  to  the  value  after  input  results  in  an  inability  to 
distinguish  between  1900  and  2000. 

•  Six-Digit  Date  Coding  is  common  in  administrative  information  systems. 
Planning  and  scheduling  systems,  human  resources  systems,  financial  and 
billing  systems,  and  many  other  programs  use  the  convention  where  a  calendar 
date  is  represented  as  two  digits  for  year,  two  digits  for  month,  and  two  digits 
for  day.  Using  six  digit  date  coding,  April  12,  1954  would  be  represented  as 
540412.  This  coding  method  is  typically  used  where  the  application  is 
attempting  to  determine  which  of  two  dates  is  earlier  in  time,  or  if  a  certain 
deadline  has  passed.  These  tests  are  frequently  coded  with  a  single  inequality 
statement  used  to  compare  the  two  six-digit  dates. 

•  Leap  Year  is  another  complicating  factor  in  the  millennium  problem.  The  year 
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2000  is  a  leap  year.  The  three  rules  which  the  Gregorian  calendar  uses  to 
determine  leap  year  are  as  follows: 

Years  divisible  by  four  are  leap  years,  unless... 

Years  also  divisible  by  100  are  not  leap  years,  except... 

Years  divisible  by  400  are  leap  years. 

Therefore,  the  year  2000  is  a  leap  year  according  to  rule  number  three.  It  is  interesting  to 
note  that  the  above  rules  apply  only  to  the  Gregorian  calendar.  Julian  dates, 
named  after  Julius  Caesar,  represented  dates  as  the  number  of  days  since  the 
mythical  founding  of  ancient  Rome.  The  Julian  calendar  invented  in  the 
Eighteenth  Century  changed  the  base  to  4713  B.C.  based  on  astronomical 
considerations.  Other  dates,  which  are  written  as  two  digits  for  the  year  and 
three  digits  for  the  day  of  the  year,  are  often  used  to  compute  the  number  of 
days  between  days.  To  calculate  the  number  of  days  between  two  given  dates, 
two  Gregorian  dates  are  translated  into  Julian  dates  and  subtracted  to  yield  the 
number  of  days  between  the  two  dates.  Different  representations  for  storing 
the  year,  month,  and  day  in  a  fixed  number  of  digits  and  shortcuts  to 
converting  dates  to  full  Julian  date  format  will  all  overflow  during  the  period 
1998-2001. 

•  Hard  coding  and  Magic  Numbers  is  another  area  of  problems  which  comes 
from  hard  coding  values  in  software  routines  such  as  “19”  for  the  implied 
century  and/or  use  of  “99”  or  “00”  as  reserved  values  meaning  “never  delete 
this”  or  “this  is  a  demonstration  account”  respectively  (sometimes  called 
“magic  numbers”)  which  limit  the  range  of  year  values  and  may  cause  date 
comparisons  to  fail  or  pollute  output  values.  Other  magic  number  dates 
include:  9/9/99,  99/99/99, 1/1/1,  1/1/11,  6/9/69,  6/7/89,  1/23/45,  6/6/66, 
7/7/77,  8/8/88,  and  12/31/99. 

•  Limiting  Date  Range  Size,  the  final  area  of  problems  concerns  platform 
limitations.  Specifically,  the  internal  date  representations  of  COTS  hardware 
and  software  components,  software  date  data  types  which  are  stored  as  an 
increment  over  some  base  date,  may  roll  over  and  fail  due  to  the  storage 
register  filling  up.  [Ref.  4] 

Exacerbating  the  issue  is  the  fact  that  the  Year  2000  problem  will  not  stop  abruptly  in 
the  Year  2000.  Year  2000  costs  will  continue  beyond  the  turn  of  the  century,  some  of 
these  costs  will  include:  fixing  Year  2000  problems  that  were  missed,  repairing  bad  fixes 
that  accidentally  introduced  new  errors,  completing  Year  2000  efforts  that  were  not 
completed  on  time,  completing  new  applications  that  were  intended  to  replace  existing 
legacy  software,  hardware  upgrades  and  performance  re-tuning  of  applications  whose 
performance  was  degraded  by  Year  2000  fixes  and  litigation  expenses  for  the  host  of 
anticipated  Year  2000  law  suits. 
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B.  EXAMPLES  OF  YEAR  2000  PROBLEMS 

According  to  multiple  sources,  including  the  June  2, 1997  issue  of  Newsweek, 
Congressional  Related  Year  2000  Hearings,  the  Software  Technology  Support  Center 
article  by  Bryce  Ragland  titled  Are  You  Ready  for  the  21st  Century?,  and  results  from 
some  DoN  assessments,  some  situations  that  may  arise  if  the  year  2000  problems  are  not 
dealt  with  include  the  following: 

•  Hospitals:  Everything  from  neonatal  monitors,  X-ray  machines  and  CT 
scanners  to  patient-record  databases,  prescription-dispensing  equipment  and 
blood-bank  dating  systems  needs  to  be  evaluated.  In  most  cases,  hospitals 
have  to  rely  on  manufacturers  to  do  the  testing. 

•  Elevators:  Most  elevators  have  embedded  systems  that  monitor  the  amount  of 
time  between  maintenance  checks.  If  these  automated  devices  calculate  that 
the  allowable  time  between  maintenance  checks  has  been  exceeded,  most 
elevators  will  go  to  the  bottom  floor  in  the  elevator  shaft,  take  themselves  out 
of  service,  and  remain  at  the  bottom  of  the  shaft  until  maintenance  is 
performed  and  the  clock  is  reset. 

•  Electricity:  When  the  Hawaiian  Electric  utility  in  Honolulu  ran  tests  on  its 
system  to  see  if  it  would  be  affected  by  the  Y2K  Bug,  “basically,  it  just 
stopped  working,”  says  systems  analyst  Wendell  Ito.  If  the  problem  had  gone 
un-addressed,  not  only  would  some  customers  have  potentially  lost  power,  but 
others  could  have  got  their  juice  at  a  higher  frequency,  in  which  case,  “the 
clocks  would  go  faster,  and  some  things  could  blow  up,”  explains  Ito. 

•  Nuclear  Power:  The  Nuclear  Regulatory  Commission  says  that  the  Bug  might 
affect  security  control,  radiation  monitoring...  and  accumulated  bum-up 
programs  (which  involve  calculations  to  estimate  the  hazard  posed  by 
radioactive. fuel).”  Radioactive  material  waste  tanks  are  monitored  and  some 
are  controlled  by  automated  sensors  and  other  devices.  They  all  work  on  date- 
sensitive  trend  analysis.  What  will  happen  to  trend  analysis  when  there  is 
perceived  to  be  a  99-year  span  between  two  measurements? 

•  Communications:  “If  no  one  dealt  with  the  year  2000  Bug,  the  phone  network 
would  not  operate  properly,”  says  Eric  Summer  Jr.,  a  Lucent  chief  technology 
officer.  He’s  not  talking  about  dial  tones,  but  things  like  billing.  Certain 
commercial  operations  that  run  phone  systems  by  computer  could  also  go 
silent  if  the  software  isn’t  fixed.  If  the  phone  system  that  malfunctions  is  the 
911  emergency  system  for  a  municipality,  the  very  lives  of  the  city’s 
population  could  be  at  risk. 

•  Medicine:  Besides  the  expected  mess  in  billing  systems,  insurance  claims  and 
patient  records,  hospitals  and  doctors  have  to  worry  about  embedded  chips  - 
microprocessors  inside  all  sorts  of  devices  that  sometimes  have  date-sensitive 
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controls.  The  year  2000  won’t  make  pacemakers  stop  dead,  but  it  could  affect 
the  data  readouts  it  reports  to  physicians  resulting  in  misinterpretation  of  data 
readouts  and  administration  of  improper  medical  care. 

•  Weapons:  Newsweek  had  obtained  an  internal  Pentagon  study  listing  the  Y2K 
impact  on  weapons  and  battlefield  technologies.  In  their  current  state,  “a  year 
2000  problem  exists”  in  several  key  military  technologies  and  they  will 
require  upgrading  or  adjustments.  One  intelligence  system  reverts  to  the  year 
1900,  another  reboots  to  1969.  The  report  confidently  states  that  as  far  as 
nuclear  devices  like  Trident  missiles  are  concerned,  “there  are  no  major 
obstacles  which  will  prevent  them  from  being  totally  Year  2000  compliant  by 
January  1999.” 

•  Money:  Banks  and  other  financial  institutions  generally  will  go  bonkers  if 
they  don’t  fix  the  year  2000  problem.  The  Senate  Banking  Committee  is  even 
worried  that  computers  might  automatically  erase  the  last  99  years’  worth  of 
bank  records.  Some  Y2K  consultants  are  advising  consumers  to  make  sure 
they  don’t  enter  the  1999  holiday  without  obtaining  hard-copy  evidence  of 
their  assets.  According  to  Jack  Webb  of  HONOR  Technologies,  Inc.,  ATMs 
won’t  work  without  fixes.  On  January  3,  1997,  trading  on  the  Brussels  stock 
Exchange  was  halted  for  three  hours  because  the  trading  system  was  unable  to 
function  after  the  date  changed  from  1996  to  1997. 

Bryce  Ragland  of  the  Software  Technology  Support  Center  speculates  On 
December  1, 1999,  you  invest  $1,000  in  a  certificate  of  deposit  (CD)  that  offers  12 
percent  simple  annual  interest.  On  January  1,  2000,  your  CD  should  be  worth 
$1,010.  Instead,  it  is  worth  -$10,990..  Just  think  what  this  could  do  to  your 
retirement,  savings  accounts,  stocks,  or  bonds.  On  the  other  hand,  if  the  computed 
interest  was  stored  in  an  unsigned  integer  field  (deposits  are  not  suppose  to  earn 
negative  interest),  your  one-month  investment  would  be  worth  +$10,990.  This 
would  be  great  for  you,  but  what  about  the  owner  of  the  investment  company  or 
the  person  in  charge  of  the  savings  plan? 

•  Food:  In  Britain  computers  at  the  Marks  &  Spencer  company  have  already 
mistakenly  ordered  the  destruction  of  tons  of  corned  beef,  believing  they  were 
more  than  100  years  old. 

•  Air  Traffic  Control:  “We  are  still  in  the  assessment  stage,  determining  how 
big  the  problem  is,”  says  Dennis  DeGaetano  of  the  Federal  Aviation 
Administration.  One  possible  danger  is  computer  lockup:  while  planes  will 
keep  moving  at  12:01a.m.  on  Jan.  1, 2000,  the  screens  monitoring  them,  if  not 
upgraded,  might  lock.  Or  the  computers  might  know  where  the  planes  were, 
but  mix  them  up  with  flights  recorded  at  the  same  time  on  a  previous  day. 

•  Factories:  Ford  Motor  Co.  reports  that  if  the  Bug  isn’t  fixed,  its  buildings 
could  literally  shut  down  -  the  factories  have  security  systems  linked  to  the 
year.  “Obviously,  if  you  don’t  fix  it,  your  business  will  stop  in  the  year  2000,” 
says  Ford’s  David  Principato.  Even  if  a  manufacturing  company  aggressively 
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solves  its  own  problem,  though,  it  might  still  have  to  close  if  its  suppliers  do 
not  deal  with  the  problem.  Most  manufacturing  plants  are  highly  automated. 

A  small  manufacturer  of  industrial  liquid  solutions  found  their  production  line 
completely  stopped  on  January  1,  1997.  It  was  discovered  that  their  process 
control  systems  were  not  designed  to  account  for  leap  year  (1996)  and 
subsequently  shut  down  when  the  year  changed  from  1996  to  1997.  Before 
the  company  personnel  could  remedy  the  situation,  the  liquid  solutions  that 
were  in  the  process  pipelines  hardened  and  could  not  be  removed.  The 
company  was  forced  to  replace  the  process  pipelines  at  a  cost  of  $1  million 

•  Automobiles:  Vehicles  could  have  as  many  as  100  chips;  if  they  are  calendar- 
challenged,  experts  say,  forget  about  driving.  Its  been  determined  that  chips  in 
some  makes  will  fail  and  the  car  will  stop  dead  at  midnight  December  31, 
1999. 

•  DMV :  The  DMV  changed  driver’s  license  expiration  dates  to  December  3 1 , 
1999  to  keep  the  renewal  systems  from  failing. 

•  State  Government:  Of  the  state  of  California’s  2600  computer  systems,  450 
are  considered  mission  critical,  these  include  computers  that  control  toll 
bridges,  traffic  lights,  lottery  payments,  prisoner  releases,  welfare  checks,  tax 
collection  and  handling  toxic  chemicals,  all  of  which  could  have  year  2000 
problems. 

•  Federal  Government:  Of  the  DoD’s  approximate  22,000  systems,  more  than 
half  are  non- Year  2000  compliant  and  include  systems  such  as  the  Global 
Positioning  System  which  uses  a  1024  week  cycle  and  rolls  back  to  January 
1980  in  August  1999,  Space  Warning  Systems  which  reject  00  as  the  year 
resulting  in  not  being  able  to  retrieve  or  delete  messages,  meteorological 
systems  which  will  not  accept  star  data  for  2000  and  beyond.  Logistics 
Information  Systems  using  2-digit  dates  which  have  already  failed  and  would 
have  erroneously  deleted  80,000  inventory  records  have  a  solution  not  been 
implemented,  command  and  control  and  information  distribution  systems  had 
incorrect  leap  year  calculations  which  prevent  messages  from  being  sent  and 
received  between  ground,  air,  and  sea. 

•  Computers  and  Software  applications:  Date  related  problems  have  already 
been  found  and,  in  some  cases,  solved  in  applications  and  computers  including 
Pentium,  Tandem,  Unisys,  Share/43,  Oracle,  Microsoft,  Visual  C++ ,  PC  Real 
Time  Clocks,  and  many  COTS  products  whose  licenses  expire  prematurely  in 
2000. 

•  Misc.:  There  are  many  other  critical,  and  common-place,  business  and 
government  systems  which  have  date  related  functions  and  could  malfunction 
at  the  turn  of  the  century.  A  partial  list  includes:  Security  systems  for  badge 
readers,  entry  gates,  vaults  and  home  security,  parking  lot  lights,  street  lights, 
uninterruptable  power  supplies,  fax  machines,  electronic  time  clocks, 
landscaping  systems,  vending  machines,  thermostats,  microwave  ovens, 
digital  watches,  televisions,  and  VCRs.  [Refs.  2,  12,  and  13] 
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The  bottom  line  is  there  are  a  lot  of  systems  that  effect  almost  every  aspect  of  our 
everyday  life.  And  none  of  them  can  be  assumed  to  be  year  2000  compliant. 


Leon  Kappelman  an  academic  and  Y2K  consultant  states  [Ref.  1],  “Anybody  who 
tells  you  ‘Oh,  it’s  OK’  without  knowing  it’s  been  tested  is  in  denial.” 

C.  ECONOMIC  IMPACT  OF  YEAR  2000  PROBLEMS 

Almost  all  computer-based  systems,  worldwide,  will  be  adversely  affected  by  the 
arrival  of  the  Year  2000,  unless  something  is  done  to  repair  or  replace  these  systems. 


As  businesses  finally  come  to  terms  with  the  inevitable,  it’s  going  to  be 
panic  time.  In  about  a  year,  expect  most  of  the  commercial  world  to  be  totally 
obsessed  with  the  year  2000  Bug... But  no  amount  of  money  or  resources  will 
postpone  the  year  2000.  It  will  arrive  on  time,  even  if  all  too  many  computers  fail 
to  recognize  its  presence.  [Ref.  1] 


Peter  de  Jager,  one  of  the  leading  proponents  of  the  year  2000  problem, 
recently  said  that  “If  you’re  not  changing  code  by  November  1997,  you  will  not 
get  this  thing  done  on  time  -  it’s  that  simple.” 

And  that  date  is  based  on  the  assumption  that  you  will  be  using  sophisticated  tools 
and  experienced  personnel  using  them.  The  start  date  to  complete  this  effort  without  tools 
and  using  inexperienced  personnel  was  a  year  ago.  Most  major  corporations  and 
government  have  year  2000  task  forces  with  varying  degrees  of  funding  and  personnel. 
Unfortunately  time  is  running  short,  some  of  the  major  companies  that  have  already  been 
expending  major  efforts  to  resolve  this  problem  are  looking  at  contingencies  if  they  don’t 
get  the  job  done. 


Peter  de  Jager  goes  on  to  state  “Those  companies  who  have  begun  to 
address  the  issue,  have  never  overestimated  the  amount  of  time  required  to  solve 
the  problem.  The  problem  has  always  proven  to  be  larger,  uglier  and  more  costly 
than  anyone  imagined.” 


What  is  going  to  happen  to  the  companies  that  have  still  not  started?  The  Gartner  Group 
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is  estimating  that  half  of  all  businesses  are  going  to  fall  short.  Some  Year  2000  experts 
predict  that  more  than  5  percent  of  all  companies  will  go  out  of  business  because  of  their 
failure  to  solve  their  Y2K  problems.  Others  estimate  the  number  to  be  as  high  as  35 
percent.  This  would  put  a  significant  number  of  people  out  of  work,  and  seriously 
impact  the  global  economy. 

According  to  what  the  Morgan  Stanley  study  maintains  is  a  conservative 
estimate,  more  than  150,000  people  will  be  needed  worldwide  to  work  on  year 
2000  compliance.  The  danger  isn’t  so  much  that  labor  costs  will  rise  further  as  it 
is  that  organizations  that  wait  too  long  will  find  no  one  available  at  any  price  [Ref 
9] 

The  Gartner  Group  estimates  the  cost  to  deal  with  Y2K  could  go  as  high  as  $600 
billion  worldwide.  That  cost  does  not  include  the  litigation  that  will  inevitably  follow  the 
system  failures. 


“You  could  make  some  very  reasonable  extrapolations  about  litigation 
that  take  you  over  $1  trillion,  and  those  are  very  conservative  estimates,  says  Dean 
Morehous,  a  San  Francisco  lawyer  [Ref.  1].” 

According  to  Vito  C.  Peraino,  a  trial  lawyer  for  Hancock  Rothert  and 
Bunshoft  in  his  testimony  before  congress  [Ref.  10],  “The  year  2000  problem 
may  represent  the  biggest  litigation  wave  our  country  has  ever  seen.” 

In  considering  the  pervasiveness  of  the  problem,  IBM  estimates  that  70 
percent  to  90  percent  of  customer  application  programs  are  affected,  Of  these 
programs,  4  percent  to  6  percent  of  the  lines  of  code  (LOC)  are  affected.  The 
New  York  Transit  Authority  provided  an  experience  report  at  a  recent  Y2K 
conference  indicating  they  found  80  percent  of  their  modules  affected,  and  1 
percent  of  the  LOC  required  modification.  At  the  same  conference,  two  insurance 
companies  said  that  between  5  percent  and  1 1  percent  of  their  LOC  required 
modification.  [Ref.  11] 

As  bad  as  it  seems  in  the  United  States,  the  rest  of  the  world  is  lagging  far 
behind  in  fixing  the  problem.  Britain  has  recently  awakened  to  the  crisis  -  a  survey 
last  year  showed  that  90  percent  of  board  of  directors  knew  of  it  -  but  the  head  of 
Britain’s  Taskforce  2000,  Robin  Guenier...(stated)  ‘I’m  not  saying  we’re  doomed, 
but  if  we  are  not  doing  better  in  six  months,  I  really  will  be  worried’.  He  expects 
the  cost  to  top  $50  billion  for  Britain  alone.  On  the  continent  of  Europe,  things  are 
much  worse... observers  fear  that  when  countries  like  Germany  and  France  finally 
tackle  the  year  2000  problem  it  might  be  too  late.  Russia  seems  complacent. 
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Mikhail  Gorbachev  met  with  Representative  Horn  in  Washington,  expressing 
concern  about  how  far  behind  Russia  is...  and  its  possible  impact  on  the  country’s 
nuclear  safeguards. [Ref.  1] 


Peter  de  Jager  wrote  in  early  1997,  “less  than  35%  of  North  American 
businesses  have  addressed  this  issue  in  any  significant  manner  and  based  upon 
informal  surveys,  Europe  is  even  further  behind,  with  less  than  10%  of 
organizations  actively  solving  this  problem.” 

And,  the  question  asked  at  the  beginning  of  this  chapter  is,  where  is  all  this 
money  going  to  come  from  to  fix  Y2K  impacted  systems?  For  commercial  companies, 
the  money  will  come  from  an  increase  in  the  price  of  the  goods  and  services  that  they 
provide.  For  the  government,  the  money  will  come  from  increased  taxes,  or  delayed, 
canceled,  or  reduced  services  they  provide.  Many  companies  may  suffer  financially  and 
this  will  effect  the  worldwide  economy. 


D.  SUMMARY 

The  Year  2000  problem  is  a  result  of  optimizing  computer  space  and  processing 
time  by  omitting  the  two  century  digits  in  date  fields.  At  the  time  it  was  done  it  made 
financial  sense.  Now  these  optimizing  techniques  could  potentially  stop  many  of  the 
world’s  computers  if  not  fixed  before  January  1, 2000. 

There  is  a  significant  amount  of  work  that  needs  to  be  done  during  the  next  2 
years.  The  effort  currently  under  way  is  to  raise  awareness  to  the  seriousness  of  the 
problem  and  to  assess  the  impacts,  risks,  costs,  and  possible  solutions.  The  pervasiveness 
of  the  Year  2000  problem  demands  a  worldwide  effort  to  ensure  that  the  computer-based 
systems  we  have  come  to  depend  upon  are  still  functioning  at  the  turn  of  the  century.  To 
fix  Year  2000  problems  does  not  demand  a  high  level  of  technical  expertise,  it  does 
demand  good  software  engineering  principles  and  solid  project  management. 

However,  The  hope  of  a  “silver  bullet”  solution  is  a  dream  that  doesn’t 
exist.  There  are  tools  that  will  help  “find”  some  of  the  problems,  in  some  of  the 
software,  on  some  of  the  hardware;  and  there  are  tools  that  will  “fix”  some  of  the 
problems,  in  some  of  the  software,  on  some  of  the  hardware.  There  aren’t  any 
tools  that  will  “find  and  fix”  all  of  the  problems  in  all  of  the  software,  on  all  of  the 
hardware.  [Ref.  12] 
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The  challenge  in  addressing  this  problem  of  unprecedented  magnitude  is 
managing  it. 

Margaret  Powell,  the  first  DoN  Y2K  Action  Officer  wrote  Managing  the  Year 
2000  effort  will  take  the  cooperation  of  professionals  at  every  level  to  be  actively 
involved.  System  owners,  users,  designers,  programmers,  and  maintainers  will  all 
need  to  understand  each  others’  roles  and  work  as  a  team.  The  challenge  is 
different  than  most  other  efforts  in  at  least  two  ways.  First,  Y2K  can  potentially 
affect  every  system  in  operation  today...Second,  the  Y2K  deadline  can  not  be 
slipped.  As  a  result,  senior  managers  face  the  unenviable  challenge  of  identifying 
the  affects  of  Y2K  within  their  organization  and  developing  sound,  economical 
strategies  to  resolve  the  problem  prior  to  the  turn  of  the  century.  [Ref.  13] 

To  quote  Peter  de  Jager,  “There  are  two  kinds  of  people,  those  who  aren’t 
working  on  the  year  2000  problem  and  aren’t  worried,  and  those  who  are  working 
on  it  and  are  terrified.” 
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II.  FEDERAL  GOVERNMENT  YEAR  2000  APPROACH  and  STATUS 


A.  FEDERAL  GOVERNMENT  YEAR  2000  STRATEGY 

The  goal  within  the  federal  government  and  private  industry  is  to  achieve  Year 
2000  compliance.  What  exactly  is  Year  2000  compliance?  The  federal  government  has 
recently  issued  the  following  definition  in  the  Federal  Acquisition  Regulation  39.002, 
dated  2  Jan.  1997: 

“Year  2000  compliant  means  information  technology  that  accurately 
processes  date/time  data  (including,  but  not  limited  to,  calculating,  comparing, 
and  sequencing)  from,  into,  and  between  the  twentieth  and  twenty-first  centuries, 
and  the  years  1999  and  2000  and  leap  year  calculations.  Furthermore,  Year  2000 
compliant  information  technology,  when  used  in  combination  with  other 
information  technology,  shall  accurately  process  date/time  data  if  the  other 
information  technology  properly  exchanges  date/time  data  with  it.” 

A  report  of  the  U.S.  Office  of  Management  and  Budget  (OMB),  Getting 
Federal  Computers  Ready  for  2000,  states  The  potential  impact  on  Federal 
programs  if  this  problem  is  not  corrected  is  substantial  and,  potentially  very 
serious.. .There  are  several  unique  characteristics  of  this  problem  that  shape  the 
Federal  strategy  for  addressing  it.  First,  it  has  an  immovable  deadline... This 
characteristic  makes  time  the  singe  most  critical  resource.  Second,  unlike  normal 
system  development  or  maintenance  activity,  many  systems  must  be  tackled 
concurrently.  Comparisons  and  computations  using  dates  permeate  computer 
systems  within  the  Federal  government,  throughout  the  State  and  local 
governments,  and  in  the  private  sector.  There  is  thus  a  real  potential  for 
substantial  strain  on  another  key  resource  -expertise.  Third,  complexity  is 
increased  by  concurrent  changes  to  multiply  systems  and  elements  within  a  system 
(e.g.,  the  operating  system).  Because  computer  systems  inter-operate  and  share 
data,  the  modified  systems  must  be  tested  together.  Furthermore,  all  of  these 
changes  must  be  made  and  tested  while  the  current  systems  continue  to 
operate...The  Government’s  strategy  is  predicated  on  three  considerations.  First, 
senior  managers  will  take  whatever  action  is  necessary  to  address  the  problem 
once  they  are  aware  of  its  potential  consequences.. .Second,  there  can  and  will  not 
be  a  single  solution.  Solving  this  problem  requires  technicians  and  engineers  to 
write  or  revise  software  code  and  to  replace  hardware.  A  “silver  bullet”  is  a 
logical  impossibility... Third,  given  the  limited  amount  of  time,  emphasis  will  be 
on  mission  critical  systems...The  Federal  strategy  relies  on  the  newly  established 
CIOs  (Chief  Information  Officers)  to  direct  that  work  and  to  follow  industry’s  best 
practices.  [Ref.  14] 
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The  current  Federal  strategy  is  dependent  on  the  involvement  of  senior 
managers  under  leadership  of  CIOs  in  each  agency,  who  in  turn  interact  with  the 
CIO  Council  and  the  Year  2000  Interagency  Working  Group  under  the 
supervision  of  OMB.  A  significant  accomplishment  of  the  Year  2000  Interagency 
Working  Group  is  the  publication  of  the  Best  Practices  guide  which  outlines  each 
phase  of  the  process  federal  agencies  should  adopt  to  address  their  year  2000 
impact.  [Ref.  7] 

The  Year  2000  Goals  and  Objectives  for  the  DoD  is  outlined  in  The  DoD  Year 
2000  Management  Plan:  The  goal  is  to  ensure  that  no  system  failures  occur  due  to  Y2K 
related  problems.  Objectives  include: 

•  Minimize  the  adverse  impact  of  Y2K  date  processing  in  all  mission  and 
mission  support  systems 

•  Define  and  share  DoD-wide,  consistent  strategies  for  finding  and  fixing  Y2K 
problems,  and  testing  solutions 

•  Minimize  the  duplication  of  effort  for  finding  and  fixing  Y2K  problems,  and 
testing  solutions 

•  Minimize  the  impact  of  resource  reallocation  to  support  Y2K  efforts 

•  Minimize  the  risk  and  cost  for  determining  the  appropriate  Y2K  solution  for 
each  system 

•  Recognize  the  Y2K  problem  as  an  opportunity  to  retire  legacy  systems  early 

•  Identify,  prioritize,  and  mobilize  the  needed  resources  for  system  conversions 
and  replacements. 

However,  the  federal  government  has  been  slow  to  recognize  the  significance  of 

the  Year  2000  problem.  A  recent  meeting  of  the  Committee  on  Government  Reform 

and  Oversight,  chaired  by  Honorable  Stephen  Horn  issued  the  following  report  on  July 

30,  1996  dealing  with  the  US  Federal  Government  Year  2000  Survey: 

As  Chairman  of  the  Subcommittee  on  Government  Management, 
Information  and  Technology,  I  am  releasing  the  results  of  a  survey  sent  to  24 
major  departments  and  agencies.  The  survey,  which  was  sent  on  April  29,  1996, 
requested  that  agencies  provide  the  subcommittee  with  a  status  report  of  when  and 
at  what  expense  agencies  plan  to  address  the  problem  of  computer  software  which 
currently  is  unable  to  recognize  the  year  2000.  The  federal  government’s  computer 
systems  rely  on  accurate  date  fields  to  calculate  age,  transfer  money,  and 
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determine  maintenance  schedules  for  national  security  systems.  Without 
converting  these  fields  to  interpret  the  turn  of  the  century,  government  systems 
could  potentially  eliminate  the  transfer  of  money,  erase  database  systems  needed 
to  send  checks  to  eligible  benefit  recipients,  and  adversely  impact  critical 
missions,  such  as  those  conducted  by  the  Department  of  Defense. 

On  April  16, 1996,  the  subcommittee  held  a  hearing  to  determine  the  extent 
of  this  computer  problem.  The  hearing  revealed  that  there  is  a  serious  lack  of 
awareness  of  the  problem  on  the  part  of  a  great  number  of  people  in  business  and 
in  government.  Even  more  alarming  was  the  cost  estimate  reported  to  the 
subcommittee  to  remedy  this  problem  which  was  said  to  be  $30  billion  for  the 
federal  government  alone.  In  response  to  these  findings  I,  along  with 
Congresswoman  Maloney,  developed  a  number  of  questions  to  better  understand 
what  federal  agencies  are  doing  to  prevent  a  possible  disaster.  Are  they  taking  the 
necessary  steps  to  identify  the  problem?  Are  they  providing  the  necessary  human 
and  capital  resources  to  correct  the  problem?  Have  they  developed  plans  to 
achieve  a  successful  launching  of  their  systems  into  the  21st  century?  The 
responses  received  from  Federal  agencies,  in  most  cases,  provided  us  with  limited 
information,  on  when  and  at  what  cost  agencies  plan  to  correct  this  potentially 
disastrous  computer  software  conversion  problem.  Even  with  this  information,  an 
outline  forms,  which  portrays  a  Federal  government  unable  to  meet  the  challenges 
of  the  21st  century  because  of  a  lack  of  awareness  and  preparedness.  Some  of  our 
major  findings  include: 

Major  departments  are  in  the  initial  planning  stages  of  this  effort,  even 
though,  agencies  need  to  have  their  systems  inventoried  and  fixed  by  1998,  in 
order  to  provide  sufficient  time  to  test  and  ensure  total  accuracy.  This  means,  in 
the  next  year  and  a  half  these  departments  must  complete  their  plans,  inventory 
and  fix  millions  of  lines  of  code,  while  simultaneously  meeting  agency  needs. 

Even  those  agencies  considered  leaders  on  this  issue,  such  as  the  Social  Security 
Administration,  and  the  Department  of  Defense  are  not  close  to  completing  the 
inventory  and  solution  stages  of  conversion.  According  to  the  information 
received,  only  six  agencies  have  cost  estimates  on  the  monetary  resources  needed 
to  solve  the  problem.  In  fact  the  Department  of  Health  and  Human  Services,  has 
cost  estimates  for  only  two  divisions,  amounting  to  $125  million.  The  Department 
of  Agriculture  has  cost  estimates  for  only  one  division,  amounting  to  $5.6  million. 
The  total  estimate  for  these  six  agencies  and  their  departments  is  $298  million. 

The  Department  of  Defense  has  not  yet  completed  its  inventory  of  computer 
software  code  which  needs  to  be  converted.  The  cost  estimate  to  fix  the  358 
million  estimated  lines  of  code  to  be  reviewed  could  cost  between  $1.02  and 
$8.52  per  line.  This  means  the  cost  to  review  and  fix  DoD  systems  could  range 
somewhere  between  $358  million  and  $3  billion.  NASA,  one  of  the  most 
innovative,  advanced  and  computer  dependent  agencies  in  the  Federal 
government,  has  not  prepared  a  plan  to  solve  the  problem  and  does  not  anticipate 
having  a  plan  completed  until  March  1997  --  this  leaves  less  than  a  year  to 
inventory,  and  fix  systems.  The  Department  of  Transportation,  which  includes  the 
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Federal  Aviation  Administration,  Federal  Highway  Administration  and  the 
Federal  Railroad  Administration  did  not  respond  to  the  questions  as  of  this  date. 
The  Department  of  Energy  did  not  begin  to  address  the  year  2000  issue  until  a 
week  after  it  received  the  subcommittee’s  survey.  [Ref.  7] 

The  latest  update  to  the  above  committees  findings  was  issued  in  the  OMB  first 
quarterly  report  to  congress  on  the  governments’  Year  2000  preparedness  issued  June  23, 
1997. 


In  it  the  committee  indicated  that  the  federal  government  will  now  spend 
$2.8  billion  to  make  its  systems  process  year  2000  dates  correctly,  up  from  an 
original  estimate  of  $2.3  billion.  This  latest  report  which  again  compiled  data 
from  24  federal  agencies,  stated  that  7,649  mission  critical  systems  had  been 
identified,  excluding  the  Social  Security  Administration,  which  reports  in 
modules.  Also,  some  agencies  reported  missing  or  incomplete  data,  so  this  total , 
along  with  cost  estimates,  will  continue  to  rise.  Of  the  total  number  of  systems,  59 
percent  are  being  repaired,  9  percent  are  being  replaced,  8  percent  are  being 
retired,  2 1  percent  are  already  year  2000  compliant,  and  3  percent  await 
evaluation.  Other  high  level  findings  indicate  that  18  of  24  agencies  are  still  in 
the  assessment  phase.  As  a  weighted  average,  the  government  is  65  percent  done 
with  its  assessment  and  17  percent  complete  with  renovation.  Cost  estimates 
exclude  normal  system  upgrades  or  replacements  as  well  as  the  federal  share  of 
state  information  systems.  Estimates  continue  to  be  termed  preliminary.  Other 
items  of  interest  in  the  OMB  report  show  six  agencies  still  working  to  complete 
their  assessments  during  the  second  half  of  this  year.  Five  agencies  plan  to 
complete  system  validations  in  the  second  half  of  1999,  including  the  Department 
of  Transportation  which,  the  report  indicates,  plans  to  finish  its  work  by 
December,  1999.  Of  the  federal  systems,  the  Social  Security  Administration 
appears  to  be  in  the  lead,  with  100  percent  of  Year  2000  mission  critical  systems 
assessed,  65  percent  converted,  55  percent  validated  and  50  percent  implemented. 
Others  reporting  relatively  fast  progress  are  the  Federal  Emergency  Management 
Agency,  the  Small  Business  Administration  and  the  Environmental  Protection 
Agency.  Those  that  appear  to  be  bringing  up  the  rear  include  the  Departments  of 
Agriculture,  Education,  Housing  and  Urban  Development,  Justice  and  National 
Science  Foundation.  The  OMB  says  that  agencies  have  made  a  good  start  in 
addressing  the  year  2000  problem.  No  mission  critical  systems  are  reported  behind 
schedule.  This  optimistic  view  is  not  shared  by  all  observers.  They  feel  that  the 
OMB  report  indicates  many  agencies  are  operating  with  a  very  narrow  window  to 
turn  their  date  problems  around.  They  also  noted  that  much  of  the  cost  identified 
in  the  report  is  limited  to  specific  year  2000  contract  spending,  while  much  of  this 
work  is  being  performed  under  existing  maintenance  and  support  contracts.  The 
Honorable  Stephen  Horn  held  hearings  last  year  to  determine  if  the  federal 
agencies  were  taking  steps  to  prevent  a  possible  computer  disaster,  and  was 
flabbergasted  at  the  lack  of  preparedness.  His  committee  assigned  each 
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department  a  letter  grade.  A  few,  notably  the  Social  Security  Administration 
(SSA),  were  given  A’s.  The  SSA  has  been  working  on  the  problem  for  eight  years 
and  now  has  it  65  percent  completed;  at  that  rate  it  will  almost  make  the  deadline. 
Those  with  no  plan  in  place,  i.e.  NASA  and  the  Veterans  Administration,  got  D’s. 
Special  dishonor  was  given  to  places  where  inaction  could  be  critical,  yet 
complacency  still  ruled,  like  the  departments  of  Labor,  Energy,  and 
Transportation.  [Ref.  15] 

One  of  the  major  challenges  facing  the  federal  government  is  how  to  determine 
the  overall  cost  of  this  effort.  The  Gartner  Group  estimates  costs  for  the  federal 
government  to  correct  the  problem  to  be  at  least  $30  billion.  Currently  the  Office  of 
Management  and  Budget  (OMB)  has  estimated  the  effort  at  $2.8  billion  which  is  up  500 
million  from  the  OMB  estimate  earlier  this  year.  The  overwhelming  scope  of  this  effort 
and  limited  modeling  data  have  resulted  in  wide  ranges  in  estimated  costs  to  resolve  the 
year  2000  problem. 


B.  DEPARTMENT  OF  DEFENSE/  DEPARTMENT  OF  THE  NAVY  YEAR 
2000  APPROACH 

The  United  States  Department  of  Defense  (DoD)  is  responsible  for  one  of  the 
largest  collections  of  systems  in  the  world.  Its  inventory  includes  numerous  hardware 
platforms,  software  programs  and  firmware  that  have  been  employed  over  the  years  to 
meet  all  of  the  information,  real-time,  and  defense  related  tasks  required  across  the 
various  branches  of  the  DoD.  So  how  is  the  Department  of  Defense  dealing  with 
achieving  Year  2000  compliance  on  the  century’s  largest  software  maintenance  project  in 
history  in  terms  of  cost  and  scope? 

On  January  31, 1997,  Mr.  Anthony  Valletta,  Deputy  Assistant  Secretary  of 
Defense  (Command,  Control,  Communications  and  Intelligence  Acquisition) 
spoke  at  “The  Millennium  Crisis:  Time  is  Running  Out  for  Federal  Agencies” 
conference,  sponsored  by  the  Information  Technology  Association  of  America 
(IT A  A)  and  Government  Computer  News.  An  excerpt  from  his  speech  highlights 
the  state  of  Y2K  in  DoD,  ‘We  understand  we  are  faced  with  a  very  serious 
situation.  In  fact,  we  are  handling  it  as  if  it  were  a  virus  which  is  set  to  become 
active  in  the  Year  2000,  and  earlier  in  some  case.  We  have  millions  of  lines  of 
code,  much  of  which  has  been  around  for  a  long  time.  The  code  all  to  often  is  not 
well-documented,  and  some  of  the  source  code  is  no  longer  available.. .(and)  we 
don’t  have  a  complete  inventory  (of  our  systems).. .Where  we  are  unique,  is  in  our 
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embedded  software  that  is  in  our  weapons  systems  —  missiles,  tanks,  planes,  and 
ships...There  are  not  enough  software  Operations  and  Maintenance  (O&M)  dollars 
to  pay  for  finding  and  fixing  Year  2000  problems,  and  testing  Year  2000  solution. 
That  means  there  will  be  tradeoffs  required... Because  of  our  extensive  inventory 
of  commercial  products  in  DoD,  we  are  especially  concerned  about  what  is  often 
referred  to  as  “systems  software;”  software  such  as  operating  systems,  and 
database  management  systems.  We  need  to  know  what  commercial  products  will 
properly  handle  the  Year  2000,  or  the  date  by  which  the  vendor  certifies  that  any 
shortcoming  will  be  corrected.  [Ref.  12] 

He  goes  on  to  outline  the  major  obstacles  he  feels  need  to  be  addressed: 
senior  management  must  be  convinced  of  the  magnitude  of  the  problem  and  get 
them  to  commit  the  resources  to  solve  it;  interfaces  among  systems  must  be  an 
area  of  focus;  and  the  January  1, 2000  deadline  is  unslippable  [Ref.  12]. 

The  DoD  Year  2000  project’s  success  will  be  determined  by  how  well  it  is  able 
to  successfully  complete  the  large  number  of  tasks,  across  the  entire  spectrum  or 
projects  and  infrastructure  throughout  the  organization.  The  Year  2000  problem  is 
primarily  an  exercise  in  large  scale  project  management.  Unlike  new  development 
projects,  year  2000  efforts  do  not  involve  leading  edge  technologies  or  unfamiliar 
methodologies.  This  effort  requires  the  same  software  engineering  skills  and  activities 
normally  used  to  develop  and  maintain  current  applications.  While  smaller  projects  may 
be  managed  on  an  ad  hoc  basis,  formal  project  management  skills  and  processes  are 
required  to  manage  the  year  2000  project.  To  this  end,  the  Department  of  Defense,  has 
adopted  a  Year  2000  approach  based  on  a  centralized  policy  with  decentralized  execution. 
This  approach,  based  on  the  Y2K  Interagency  Working  Group  Best  Practices,  is  made  up 
of  five  specific  phases.  The  five  phases  ensure  that  each  system  is  fully  assessed  for  Y2K 
impact,  a  plan  is  developed  to  correct  any  and  all  problem(s),  the  correction(s)  are  fully 
tested,  and  the  system  is  back  in  full  operation  by  the  deadline  of  November  1999.  DoN 
Year  2000  correction  efforts  are  categorized  into  these  five  phases,  and  within  each  of 
these  phases  is  a  set  of  tasks  to  be  completed. 

Each  DoN  system  may  only  require  the  execution  of  some  of  the  tasks, 
depending  on  the  nature  of  the  system’s  Year  2000  problems  and  the  specifics  of 
the  system's  life-cycle  and  operational  situation.  Additionally,  some  system  Year 
2000  “fixes”  may  include  hardware  replacements  and  upgrades.  For  systems 
requiring  all  of  the  steps,  the  cost  will  still  be  a  function  of  several  factors 
including:  the  types  of  Year  2000  problems  facing  the  system,  the  chosen 
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solutions,  the  efficiency  of  the  maintenance  workforce  making  the  corrections,  the 
languages  in  the  system,  the  type  of  application,  and  the  level  and  complexity  of 
testing  required.  [Ref.  16] 

Following  is  a  list  of  the  five  phases  and  the  tasks  associated  with  each  phase.  For  a 
complete  copy  of  the  DoD  Year  2000  Management  Plan,  and  more  descriptions  of  these 
phases  and  tasks,  see  the  Department  of  Defense  home  page  located  at 
http://www.doncio.navy.mil/y2k/dodmgtpln.doc 

•  AWARENESS  PHASE: 

•  Define  the  problem 

•  Establish  the  project  team 

•  Obtain  high  level  management  support 

•  Make  a  business  case 

•  Decide  upon  an  overall  approach 

•  Make  oral  and  written  presentations 

•  Publish  articles  in  agency  technical  newsletters 

•  Prepare  articles  for  corporate  publications 

•  Brief  each  application  area 

•  Identify  technical  and  management  representatives  for  each  department 

•  Move  beyond  the  IT  community 

•  Brief  non  systems  departments 

•  Determine  exposures  in  infrastructure: 

•  Access/environmental/elevators/security/fire 

•  Define  terms  (Glossary) 

•  Establish  compliance  standards  for  new  systems 

•  Start  preparation  of  project  plan 

•  ASSESSMENT  PHASE: 

•  Code  inventory 

•  Develop  methodology  for  conducting  inventory 

•  Select  inventory  team 

•  Conduct  inventory  of  source  code 

•  Determine  LOC 

•  Identify  languages 

•  Collect  survey  information 

•  Missing  source  code 

•  Identify  tasks  related  to  missing  source  code 

•  Map  source  to  executables 

•  Prepare  a  list  of  no  source  modules 
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•  Determine  which  modules  must  be  re-created 

•  Assign  responsibility  for  re-creating  lost  code 

•  Rewrite  needed  missing  modules 

•  Identify  source  recovery  vendor 

•  Vendor  software 

•  Contractor  maintained  software 

•  Pilots 

•  Determine  need  for  pilots 

•  Conduct  pilots 

•  Submit  pilot  code  to  vendors  for  comparison 

•  Make  decision  on  manual  vs  automated  method 

•  Make  decision  on  in  house  resources  vs  contractors 

•  Identify  technical  issues  requiring  resolution 

•  Form  technical  team 

•  Screen  input  issues 

•  Determine  strategy  for  screen  dates  (2  or  4  position) 

•  Print  and  distribute  decision  paper 

•  Forms 

•  Form  subgroup  to  handle  issues  relating  to  forms 

•  Resolve  issues  with  pre-printed  forms 

•  Resolve  issues  with  computer-generated  forms 

•  Estimating  system  costs  for  the  year  2000 

•  Survey  available  tools 

•  Conduct  procurement  for  tools  and/or  services  if  necessary 

•  Determine  costs  using  survey  results  and  industry  standards 

•  Prepare  master  schedule  for  Renovation  and  Validation  Phases 

•  Conduct  risk  analysis 

•  Prioritize  systems  for  future  phases 

•  Make  decisions  on  modification,  re-engineering  and  retirement  of  systems 
/programs 

•  Decide  on  validation  approach 

•  Identify  data  exchanges  handled  by  operations,  application  areas,  and  non 
systems  departments 

•  Resolve  date  formats 

•  Establish  schedule  for  conversion  of  data  exchanges 

•  Determine  need  for  bridges/filters 

•  Complete  preparation  of  project  plan 

•  RENOVATION  PHASE: 

•  Implement  standardized  date  routines 

•  Re-Engineer  selected  systems/programs 
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•  Retire  selected  systems/programs 

•  Determine  strategy  for  code  modification  by  system  (expand/algorithm/sliding 
scale/bridge) 

•  Install  and  utilize  selected  year  2000  tools 

•  Develop  bridges/filters 

•  Re-create  missing  source  code 

•  Change  files  and  databases 

•  Validation  Phase 

•  Create  isolated  future  testing  environment 

•  Determine  resources  needed 

•  Storage 

•  Processing  capacity 

•  Resolve  technical  issues 

•  Determine  how  files  will  be  aged 

•  Volume  testing  vs  individual  case  testing 

•  Establish  validation  databases 

•  Coordinate  future  validation  efforts  with  ongoing  development 

•  Utilize  existing  tools 

•  Regression  test  all  changed  systems 

•  Future  date  test  all  changed  systems 

•  IMPLEMENTATION  PHASE: 

•  Schedule  implementation  of  all  changed  systems,  vendor  software  and 
hardware 

•  Make  decision  on  parallel  processing 

•  Resolve  data  exchange  issues 

•  No  data  received 

•  Bad  data  received 

•  Consider  use  of  hot  sites  for  file  conversion 

•  Decide  on  handling  of  archive  files 

•  Develop  backup/recovery  plans 

•  Project  Management 

•  Form  Systems  Project  Team 

•  Form  Non-Systems  Project  Team 

•  Conduct  status  meetings 

•  Track  progress  to  plan 

•  Develop  funding  requirements  and  develop  strategies  for  funding 

•  Brief  senior  management  on  status 


Following  is  the  current  DoN  schedule  for  completion  of  each  of  the  five  phases: 
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Phase 

•  Phase  One  -  AWARENESS 

•  Phase  Two  -  ASSESSMENT 

•  Phase  Three  -  RENOVATION 

•  Phase  Four  -  VALIDATION 

•  Phase  Five  -  IMPLEMENTATION 


Planned  Completion  Date: 
December  1996 
June  1997 
December  1998 
January  1999 
November  1, 1999 


C.  DEPARTMENT  OF  DEFENSE  YEAR  2000  STATUS 

Figure  1  represents  the  Year  2000  status  within  the  DOD  as  of  July  1997.  Over 
50%  of  the  systems  in  the  DOD  are  currently  reporting  as  non  Year  2000  compliant.  It  is 
obvious  from  this  report  that  the  DOD  has  a  significant  effort  ahead  in  order  to  resolve 
the  year  2000  problem.  The  majority  of  its  systems  are  in  the  Assessment  and  Renovation 
phases.  If  the  DOD  experience  is  similar  to  that  of  private  industry,  they  will  begin  to  find 
they  have  underestimated  this  effort  as  they  get  deeper  into  the  Renovation  phase. 

D.  DEPARTMENT  OF  THE  NAVY  YEAR  2000  STATUS 

The  DoN  has  adopted  the  5  phased  approach  promulgated  by  the  DOD  and  has 
issued  the  DoN  Year  2000  Action  Plan  detailing  the  actions  necessary  to  implement  that 
approach  within  the  DoN.  The  following  outlines  the  current  status  of  the  DoN  in 
implementing  the  Year  2000  Action  Plan: 

The  DoN  has  placed  a  high  priority  on  Year  2000  compliance  for  its  systems.  In 
March  1997  they  conducted  a  Year  2000  status  review  with  each  of  the  System 
Commands,  the  Bureau  of  Medicine  and  Surgery,  and  the  Bureau  of  Naval  Personnel. 
Representatives  from  CNO,  and  the  Atlantic  and  Pacific  Fleets  attended  the  review.  The 
results  revealed  that  additional  systems  are  being  identified  that  were  not  originally 
assessed,  additional  non-compliance  status  is  being  reported  by  commercial  off  the  shelf 
(COTS)  vendors,  and  the  overall  costs  are  increasing.  It  was  determined  that  the  DoN 

Chief  Information  Officer  (CIO)  would  conduct  quarterly  Year  2000  reviews  to  expedite 
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resolution  of  the  Year  2000  problem.  As  indicated,  the  DoN  has  adopted  the  DOD  five 
phased  approach  to  the  resolution  of  the  Year  2000  problem.  Currently  approximately 
70%  of  the  DoN  systems  have  completed  the  Assessment  phase.  The  estimated  cost  to  fix 
the  DoN  Year  2000  problem  is  $234M.  The  goal  for  the  DoN  is  to  have  every  mission 
critical  system  Year  2000  compliant  by  December  1998,  giving  them  all  of  1999  to 
perform  comprehensive  intersystem  tests. 

Because  of  the  potential  far-reaching  impacts  of  not  properly  addressing  interfaces 
among  systems,  the  DoN  CIO  is  requiring  that  each  functional  area  conduct  a  Year  2000 
Interface. 
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Figure  1.  DOD  System  Status 


Assessment  to  ensure  that  information  systems  and  processes  that  pass  data  to  other 
systems  are  being  addressed,  and  will  be  Year  2000  compliant,  and  tested,  prior  to 
January  1, 2000.  As  of  July  1997  initial  interface  assessments  had  been  conducted  for  the 
Financial,  Intelligence,  Logistics,  Command  and  Control,  and  Communications 
functional  areas.  The  Communications  interface  assessments  included  such  areas  as 
AUTODIN/DMS,  DISN,  FLTSATCOM,  Navy  Telecommunications  Network 
Management  Systems,  ELF  communications.  Air  Force  Network  Control  Center, 
AFSATCOM,  MILSTAR,  Theater  Deployable  communications  and  Telephone  switches 
for  all  services.  Functional  areas  yet  to  be  assessed  include  Military  Personnel  and 
Readiness,  Procurement/Contract  Administration,  Civilian  Personnel,  Information 
Management,  Space,  Meteorology,  Systems  Acquisition  Management,  Weapons, 
Environment  Security,  Health  Affairs,  Science  and  Technology,  Test  and  Evaluation, 
Nuclear,  Chemical  and  Biological,  Reserve  Affairs,  Transportation,  and  Industrial  Affairs 
and  Installations.  These  interface  assessments  will  be  repeated  for  all  functional  areas 
until  there  is  assurance  that  the  Year  2000  problems  in  those  areas  have  been  resolved. 

Based  on  a  July  19,  1997  Navy  SITREP  promulgated  by  RADM  Stephen  Johnson, 
Commander  Naval  Information  Systems  Management  Command,  some  specific  examples 
of  DoN  systems  Year  2000  status  include: 

•  Trident:  In  view  of  the  nuclear  weapons  nature  of  the  tactical  software  and 
hardware,  it  is  reviewed  and  updated  on  a  regular  basis,  therefore,  analysis 
and  assessment  on  all  tactical  systems  has  been  completed.  Based  on  this 
assessment,  all  corrections  have  been  identified  and  have  either  already  been 
corrected  or  will  be  corrected  prior  to  Year  2000  as  part  of  normal  system 
upgrades  using  existing  funding.  The  Year  2000  problem  will  not  cause  any 
disruption  to  the  operation  of  the  Strategic  Weapon  System  and  there  is  no 
major  obstacles  which  will  prevent  this  system  from  being  totally  Year  2000 
compliant  by  January  1999. 

•  Cruise  Missile:  In  view  of  the  weapons  nature  of  the  Cruise  Missile  system  all 

tactical  software  and  hardware  is  reviewed  and  updated  on  a  regular  basis. 

Analysis  and  assessment  of  the  tactical  systems  reflects  that  those  systems 
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which  have  identified  as  having  a  Year  2000  impact  will  be  fixed  in 
subsequent  releases  prior  to  Year  2000  impact. 

•  AEGIS:  The  AEGIS  Weapon  System  (AWS)  was  analyzed  for  impact  due  to 
the  Year  2000  problem.  Calendar  date  is  not  a  variable  in  the  AWS  processing 
to  deliver  ordinance  on  target.  Testing  has  been  conducted  in  the  AEGIS 
computer  center  and  no  anomalies  were  identified  in  the  Ordnance  on  target 
processing.  The  only  errors  identified  were  incorrect  display  of  the  year  in  one 
CRT.  This  will  be  corrected  in  the  next  release.  Year  2000  certification  will  be 
included  in  the  annual  combat  system  integration  test. 

•  Global  Positioning  System  (GPS),  will  be  ready  for  both  the  End-of-Week 
and  Year  2000  rollovers.  The  GPS  Joint  Program  Office  has  been  working 
this  problem  for  years  and  have  exhaustively  analyzed  the  problem  and  have 
an  action  plan  in  place  and  are  on  track.  They  plan  to  replace  legacy  systems, 
that  are  not  Year  2000  compliant,  with  a  new  system. 

•  Telephone  switches:  All  the  services  have  a  major  telephone  switch  problem. 
NCTC  is  currently  evaluating  the  problem  for  the  Navy.  Currently  the  DoN 
has  approximately  64  non-compliant  telephone  switches  at  an  estimated  cost 
to  fix  of  $45M. 

•  Facilities:  NAVFAC  staff  coordinated  with  the  Naval  Facilities  Engineering 
Services  Center  to  propose  a  plan  for  assessment  of  facilities,  systems  with 
embedded  information  technology  (IT).  The  proposal  is  being  submitted  for 
consideration.  The  assessment  could  include  elevators,  digital  device 
controllers,  security  systems,  boiler  control,  energy  management  and  control 
systems,  remote  metering,  and  other  facilities-related  embedded  IT.  A  pilot 
project  will  be  conducted  at  San  Diego  and  Norfolk  to  determine  the  extent  of 
this  problem.  As  of  July,  funding  has  not  been  provided  for  this  project. 

•  Contracts:  The  Naval  Information  Systems  Management  Center  has  recently 
awarded  an  Information  Technology  Support  Services  Blanket  Purchasing 
Agreement.  This  contracting  vehicle  will  allow  contracting  officers 
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immediate  assess  to  vendors  that  provide  Year  2000  solutions  to  their 
software  problems. 

NAVSEA:  Their  solution  of  choice  is  to  re-host  business  systems  and 
upgrade  weapons  systems  through  the  maintenance  process.  NAVSEA 
expects  all  systems  to  be  implemented  as  Year  2000  compliant  by  June  1999. 
NAVSEA’ s  major  risk  will  be  the  ability  to  obtain  short  fall  funding  and  the 
potential  impact  on  its  customers  where  funds  must  be  redirected  from 
meeting  operational  commitments  due  to  lack  of  sufficient  resources. 
Estimated  cost  impact  to  NAVSEA  is  $8M. 

NAVSUP:  They  have  targeted  full  implementation  by  December  1998. 
NAVSUP’s  Year  2000  effort  is  supported  by  a  Fleet  Material  Support  Office 
tiger  team.  They  have  identified  308  systems  to  assess  for  Year  2000 
compliance,  17  of  which  are  mission  critical.  Renovation  is  underway  on  58 
systems  and  55  are  already  Year  2000  compliant.  At  least  34  system  are 
scheduled  to  be  out  of  production  by  2000.  NAVSUP’s  risks  center  around 
resources:  funding  $16M,  availability  of  Year  2000  tools  for  DoD  wide  use, 
and  test  facilities  at  the  Defense  MegaCenters.  The  test  facilities  risk  is  also 
identified  by  BUPERS  and  is  contingent  on  the  DMC’s  being  upgraded  to 
OS390,  a  Year  2000  compliant  operating  system. 

NAVAIR:  The  NAVAIR  community  organized  a  team  of  8  team  leaders  and 
62  competency  members  to  develop  and  execute  a  top-level  plan  for  ensuring 
Year  2000  compliance.  NAV AIR’s  strategy  is  to  prioritize  their  4392 
systems  (2260  are  already  Year  2000  compliant,  562  are  in  renovation,  1372 
have  not  completed  assessment,  and  172  will  be  terminated  by  2000)  as 
mission-critical,  mission-essential,  NAVAIR-wide  systems,  and  other  local 
systems.  NAVAIR  identified  a  cost  impact  of  approximately  $9M. 

BUPERS:  Identified  73  systems  as  mission  essential.  The  Year  2000  will 
impact  mobilization,  re-enlistment,  manning  readiness,  and 


manpower/personnel  requirements.  The  strategy  is  for  system  migration  to 

new  applications,  DBMS,  and  client-server  environment,  assimilating  legacy 
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systems  functionality  into  new  information  systems.  BUPERS  is  tracking  the 
delivery  of  new  or  migration  systems  which  will  impact  termination  of  7 
legacy  systems,  3  of  which  have  contingency  plans  already  in  place. 
BUPERS  identified  several  major  risks:  funding,  resolution  of  data 
exchange  issues,  and  availability  of  test  facilities. 

NAVFAC:  Their  assessment  of  74  AIS  systems  indicated  that  40  systems 
are  under  renovation  and  14  systems  report  no  Year  2000  problems. 
NAVFAC  indicated  that  fixes  for  its  AIS  systems  were  minor  programming 
changes.  Some  fixes  will  not  be  in  place  until  the  next  scheduled  releases  of 
the  application  software. 


E.  SUMMARY 

It  has  become  apparent  from  the  testimony  before  congressional  subcommittees 
by  top  managers  of  federal  agencies  that  there  is  wide  disagreement  over  the  severity  of 
the  year  2000  problem  within  the  federal  government.  Some  managers  are  confident  the 
current  Year  2000  effort  will  be  successful,  while  others  are  calling  for  the  federal 
government  to  speed  up  compliance  efforts  because  the  majority  of  the  federal  agencies 
did  not  plan  to  finish  their  Year  2000  compliance  efforts  until  November  or  December 
1999,  which  would  leave  no  room  for  error.  In  the  current  report  to  Congress,  just  18  of 
24  agencies  had  completed  assessments  of  their  year  2000  efforts  by  the  federally 
mandated  due  date  of  June  1997.  The  six  agencies  not  meeting  the  deadline  account  for 
an  estimated  70  percent  of  the  total  cost  of  compliance. 

Joel  Willmessen,  the  top  Y2K  watcher  at  the  General  Accounting  Office, 
stated  OMB’s  perspective  that  agencies  have  made  a  good  start  and  that  no 
mission-critical  systems  were  reported  to  be  behind  schedule  would  seem  to  imply 
that  there  is  no  cause  for  alarm.  On  the  contrary,  we  believe  ample  evidence 
exists  that  OMB  and  key  federal  agencies  need  to  heighten  their  levels  of  concern 
and  move  with  more  urgency.  [Ref.  7] 

In  an  analysis  of  testimony  before  Congress  in  July,  and  as  reported  in  an 
ITAA  Weekly  Outlook  report,  the  Gartner  Group  felt  the  fact  the  government  was 
dealing  with  the  problem  at  this  high  level  was  a  positive  sign,  however,  based  on 
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the  fact  that  large  scale  government  projects  seldom  meet  even  optimistic 
schedules,  they  expressed  concern  that  a  proposed  November  1999  completion 
date  posed  a  high  risk,  and  that,  if  anything,  the  report  underestimated  the 
government’s  problems.  They  stated  that  enterprises  at  this  phase  of  their  year 
2000  efforts  often  significantly  underestimate  their  cost  of  compliance  because  of 
excessive  optimism,  downright  ignorance,  or  both.  The  Gartner  Group 
recommended  that  to  meet  the  Year  2000  deadline,  federal  offices  and  agencies 
should  first  complete  an  assessment  and  define  their  applications'  “time  horizon 
to  failure”  which  is  the  date  at  which  applications  with  forward  looking 
calculations  will  fail  and  cannot  be  fixed  in  the  time  left  for  normal  maintenance. 
These  organizations  must  then  develop  plans  to  achieve  Year  2000  compliance 
throughout  their  agency  within  this  time  horizon.  Although  almost  two-thirds  of 
this  planning  is  complete,  some  of  the  due  dates  of  projects  fall  in  very  late  1999. 
Since  the  vast  majority  of  IT  projects  are  canceled,  completed  late,  or  delivered 
with  scaled-down  functionality  (in  this  case,  failure  would  likely  manifest  itself  as 
poor  quality),  there  is  a  significant  risk  when  plans  do  not  include  explicit  buffer 
periods  to  insulate  the  project.  The  year  2000  problem  will  not  cause  the  U.  S. 
government  to  go  out  of  business.  However,  the  business  community  must  also  be 
concerned  since  they  will  be  directly  affected  by  additional  taxes  required  to 
correct  the  problem  beyond  2000  or  by  the  inability  of  U.  S.  (or  other)  government 
agencies  or  offices  to  deliver  adequate  services.  Finally  they  felt  that  private 
industry  needed  to  develop  a  risk  assessment  plan  dealing  with  the  impact  on 
them  due  to  failures  resulting  from  year  2000  governmental  noncompliance. 

The  Gartner  Group  recommended  the  U.  S.  government’s  efforts  to 
address  the  year  2000  problem,  need  to  accelerate,  and  that  the  U.  S.  Congress 
should  support  their  efforts  by  allocating  sufficient  funds  to  do  so.  Currently  the 
agencies  are  being  expected  to  absorb  this  cost  out  of  current  funding  which  has 
seriously  effected  the  effort  and  resources  that  have  been  placed  on  this  task. 
Oversight  committees  have  devoted  much  attention  to  determining  exactly  how 
much  the  compliance  effort  will  cost.  “Exact”  is  certainly  a  misnomer  in  this 
context  because,  without  detailed  assessment  and  solution  design,  any  estimate 
will  almost  certainly  be  wrong.  Instead  of  estimate  overkill,  scarce  resources 
should  be  applied  to  fixing  the  problem.  The  year  2000  will  not  go  away;  it  will 
cost  what  it  will  cost,  and  it  will  cost  more  tomorrow  than  it  does  today.  [Ref.  15] 
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III.  YEAR  2000  COST  ESTIMATION  WITHIN  THE  DOD 


A.  DOD  COST  ESTIMATION  APPROACH 

At  this  point,  it  is  difficult  to  know  if  the  problem  is  a  $358  million  or  a 
$3  billion  problem  for  the  DOD  because  of  the  uncertainty  in  estimating  the  scope 
and  resolution  effort.  A  1995  MITRE  study  of  approximately  5.4  million  lines  of 
code  from  nine  command  and  control  systems  and  two  logistics  systems  showed 
that  approximately  1.16  percent  of  the  code  dealt  with  date  manipulation.  The 
MITRE  study  estimated  the  cost  of  corrective  maintenance  to  these  systems  at 
between  $.75  to  $1.70  per  line  of  code  (LOC)  for  application  information  systems 
and  $1  to  $8.52  per  LOC  for  command  and  control  systems.  [Ref.  16] 

The  Assessment  phase,  in  which  the  majority  of  the  DOD  is  currently  engaged, 
deals  with  those  activities  required  to  define  the  scope  of  the  problem  and  set  up  the 
infrastructure  necessary  to  solve  it.  The  primary  purpose  of  the  Assessment  Phase  is  to 
gather  and  analyze  information  in  order  to  determine  the  size  and  scope  of  the  problem. 
Only  after  the  size  and  scope  have  been  determined,  can  an  estimate  of  the  cost,  in  terms 
of  dollars  and  work  years,  be  made. 

On  January  14,  1997  Emmett  Paige,  Jr.,  OSD/C3I,  wrote  it  is  important 
that  we  use  a  single  cost  estimating  metric  in  our  reports  to  congress,  OMB,  and 
others.  The  estimates  furnished  now  will  be  revised  as  we  move  along  in  the 
overall  process.  The  metric  we  will  use  is  executable  lines  of  code  (ELOC)  x 
$1.10  for  all  automated  information  systems  except  for  embedded  weapon 
systems,  for  embedded  weapon  systems  we  will  use  executable  lines  of  code  X 
$8.00.  These  estimates  will  be  refined  by  each  Mildep/agency/CINC’s/OJCS  as 
the  assessment  phase  is  completed.  I  recognize  that  in  some  cases  you  might 
already  have  more  accurate  estimates  for  specific  systems.  Where  required  to 
break  the  estimates  down  in  finer  detail  than  reflected  above,  we  will  use  that 
more  refined/more  accurate  information  with  an  explanation  for  each  specific 
estimate  that  explains  the  metrics  used  to  compute  that  cost. 

This  was  done  to  standardize  the  estimates  between  organizations  and  throughout 
organizations  and  provides  the  first  indication  of  the  level  of  effort  which  must  be 
accomplished.  Although  this  is  a  “ballpark”  estimate,  it  nevertheless  provides  a  common 
basis  for  comparison  across  government  and  industry. 

Once  a  rough  work  year  estimate  has  been  obtained,  it  is  time  to  begin  an  in-depth 
analysis  of  the  costs  associated  with  solving  the  Year  2000  problem.  For  many 


31 


organizations,  there  will  be  a  single  opportunity  to  request  funding.  It  becomes  very 
important,  therefore,  to  make  the  cost  estimation  as  accurate  as  possible.  There  are  a 
number  of  factors  which  will  influence  the  cost  of  making  code  Year  2000  compliant  in 
addition  to  modifying  software.  These  factors  include  building  the  test  environment, 
buying  tools  and  services,  adding  hardware,  upgrading  operating  system  software  and 
commercial  products,  etc.  The  Department  of  Defense  has  developed  a  checklist  for 
estimating  costs  for  the  year  2000.  Appendix  B  includes  a  copy  of  the  “Year  2000  Cost 
Factors”  checklist  that  serves  as  an  aid  in  estimating  system  year  2000  costs.  The 
checklist  indicates  those  areas  where  costs  should  be  adjusted  because  of  specific 
environment. 

The  Gartner  Group  is  an  independent  advisor  to  business  professionals  making 
information  technology  (IT)  decisions.  They  have  developed  the  following  Year  2000 
cost  estimation  aids  for  program  managers.  Applying  this  formula  requires  an  accurate 
system  inventory  which  includes  source  lines  of  code  (SLOC).  This  formula  provides  a 
rough  estimate,  plus  or  minus  40  percent  of  the  actual  cost  and  includes  project 
management,  labor  costs,  locating  and  identifying  affected  code/data,  parsing  and 
analyzing  for  affected  code  data,  determination  of  options,  implementation  of  solutions, 
unit  and  integration  testing,  and  implementation.  The  following  estimation  formula  was 
developed  by  the  Gartner  Group  and  adopted  by  the  DOD.  A  two  step  process  can  be 
used  to  produce  a  rough  order  of  magnitude  for  system  applications. 

Step  1:  Multiply  SLOC  x  .80.  This  will  determine  executable  lines  of  code  (ELOC). 

Step  2:  Multiply  ELOC  x  $1.70.*  for  AIS  systems 
Multiply  ELOC  x  $8.00  for  Weapon  Systems 
Note:  *The  Gartner  Group  recently  increased  this  figure  from  a  $1.10  to  $1.70. 

The  Gartner  Group  also  proposes  that  application  complexity  can  be  estimated, 
and  used  to  further  refine  the  cost  estimate,  provided  other  information  is  available  such 
as  the  following: 

•  Function  of  component 

•  Type  of  component  (create,  read,  delete,  update) 
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•  Number  of  physical  transaction  paths  in  the  component  and  which  ones 
involve  dates  or  date-based  operations 

•  Amount  and  type  of  actions  in  which  dates  are  used  (e.g.,  sort,  compute  and 
“if’  statements) 

•  Age  and  size  of  application  (an  indicator  of  applied  methods  and  technology) 

•  Date  field  count 

•  Date/LOC  ratio 

Examples  of  complexity  classifications  include: 

Simple:  5-15  hours 
Moderate:  15  -  30  hours  and 
Complex:  30  -  45  hours 

The  formula  is  (hours  x  rate)  x  ( percent  x  total  components). 

For  example: 

For  8,000  components  (20%  Complex,  50  %  Moderate,  and  30  %  Simple),  the 
estimate  range  would  be  $7.2M  to  S13.7M. 

The  Gartner  Group  also  provides  a  date  field  expansion  estimate  based  on  $3.00 
to  $4.50  per  data  record.  This  includes  programming  modifications  required  for 
accommodation  of  the  new  date  format.  Date  field  expansion  is  likely  to  affect  a  greater 
percentage  of  programs  than  a  programmatic  solution,  and  represents  increased  logistical 
and  project  management  costs  due  to  the  need  to  replicate  and  modify  databases,  and  due 
to  interface  requirements.  Depending  on  the  year  2000  solution  selected  and  the 
information  available  the  above  approaches  will  help  in  providing  a  high  level  year  2000 
cost  estimate. 

The  MITRE  Corporation,  an  independent  consultant  for  the  federal  government, 
recently  released  the  following  costs  estimates  in  an  effort  to  help  DOD  services  and 
agencies  develop  rough  orders  of  magnitude.  To  get  an  understanding  of  how  the  Year 
2000  problems  will  impact  military  systems,  they  analyzed  a  range  of  applications  from 
across  the  services  which  included  Ground  and  Airborne  Radar  Systems, 
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Communications  Processing  Systems,  Command  and  Control  (C2)  Planning  Systems, 
and  Logistics  Support  Systems.  For  these  types  of  systems  their  analysis  showed  a  range 
of  costs,  calculated  as  a  function  of  the  executable  lines  of  code,  as  follows: 

•  Ground  and  Airborne  Radar  Systems:  $2.02  -  $8.52  per  LOC 

•  Communications  Processing  Systems:  $  1 .23  -  $5.54  per  LOC 

•  C2  Planning  Systems:  $  1 .22  -  $  1 .84  per  LOC 

•  Logistics  Support  Systems:  $  1 .02  -  $  1 .39  per  LOC 

•  MIS  Systems:  $0.75  -  $  1 .70  per  LOC 

However,  these  costs  may  not  be  what  real  systems  experience.  For  example,  if  a 

system  is  under  maintenance  with  scheduled  releases  and  upgrades,  the  Year  2000 
changes  can  be  rolled  into  the  ongoing  changes  for  testing  and  fielding  purposes,  thus 
avoiding  separate  Year  2000  activities  for  these  two  steps.  This  is  especially  significant 
for  systems  which  require  test  ranges  and  test  vehicles  or  that  require  secure  operation 
and  have  high  availability  requirements,  since  the  testing  and  fielding  steps  for  these 
systems  are  extremely  expensive  and  complex. 

B.  EVALUATION  OF  YEAR  2000  COST  DRIVERS  WITHIN  THE  DOD 

Figure  2  lays  out  the  year  2000  cost  drivers,  which  were  identified  as  a  result  of 
this  case  study,  as  being  either  unique  to  a  Year  2000  effort  or  deviate  significantly  from 
values  currently  used  in  parametric  costing  models  for  traditional  software  development 
or  maintenance  efforts.  Pluses  and  minuses  indicate  the  relative  degree  to  which  these 
cost  factors  will  effect  cost  estimates  for  the  year  2000.  The  following  paragraphs 
describe  each  of  these  unique  year  2000  cost  factors: 

•  RESOURCE  AVAILABILITY  -  Resources  include  people/labor,  time, 
money.  The  resources  to  fix  the  year  2000  problem  will  become  harder  to 
come  by  as  the  year  2000  approaches. 
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Figure  2.  Year  2000  Cost  Drivers 
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According  to  what  the  Morgan  Stanley  study  maintains  is  a  conservative 
estimate,  more  than  150,000  people  will  be  needed  worldwide  to  work  on  year 
2000  compliance.  The  danger  isn’t  so  much  that  labor  costs  will  rise  further  as  it 
is  that  organizations  that  wait  too  long  will  find  no  one  available  at  any  price 
[Ref.  9] 


Despite  the  soaring  costs,  Gartner’s  Hall  warns  against  obsessing  over 
them.  Companies  should  instead  keep  a  close  eye  on  the  calendar,  because  we  are 
limited  by  resources,  not  cost.  [Ref.  9] 

With  the  Year  2000  problem  this  may  not  be  possible  due  to  the  enormity  and 
breadth  of  the  effort  worldwide.  Also,  some  legacy  systems  that  have  been  in  a  caretaker 
status  for  some  time  with  no  plans  to  modify  have  no  existing  experts  available.  Many  of 
these  systems  are  written  in  old  languages  and  may  have  few  resources  available.  As 
several  year  2000  experts  have  indicated,  the  date  to  start  making  systems  year  2000 
compliant,  using  experts  with  advanced  tools,  with  a  reasonable  expectation  of 
completing,  is  October  1997.  The  date  to  begin  this  effort  with  average  technical 
personnel  without  sophisticated  tools  was  last  year.  As  has  been  emphasized  the  due  date 
for  this  project  cannot  be  slipped.  Historically,  the  majority  of  large  software  projects  are 
not  completed  on  time.  The  current  schedule,  being  proposed  by  the  various  services,  i.e. 
completion  by  November  1999,  allows  very  little  room  for  such  delays.  The  current 
approach  within  the  DOD  is  that  the  various  services  will  take  the  cost  of  this  effort  out 
of  existing  funding.  This  approach  has  seriously  impacted  the  ability  of  the  services  to 
respond  in  a  rapid  manner. 

•  RESOURCE  COST  -  The  cost  of  resources  to  find  and  fix  the  Year  2000 

problems  will  increase  significantly  as  the  year  2000  approaches. 

Bruce  Hall,  research  director  for  application-development  methods  and 
management  at  the  Gartner  Group  Inc.,  says  labor  costs  for  Year  2000  projects 
are  up  30%  since  last  year,  when  they  averaged  $60  an  hour,  and  are  still 
climbing.  The  revised  labor  cost  works  out  to  about  $1.50  per  line  of  code,  up 
from  $1.10.  The  increase  may  lead  Gartner  to  raise  its  widely  cited  estimate  of 
$300  -  $600  Billion  for  all  corporate  year- 2000  projects.  This  dramatic 
increase  in  labor  costs  is  driving  more  US  firms  to  hire  overseas 
programming  companies  to  do  their  year  2000  work,  which  could  increase 
significantly  during  the  next  year.  One  study  estimated  that  15%  of  companies 
are  moving  toward  outsourcing  their  year  2000  work,  of  these,  25%  are 
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moving  the  work  offshore.  Analysts  estimate  that  overseas  companies 
typically  charge  40  percent  -  50  percent  less  than  US  firms  for  the  same  job. 
[Ref.  9] 

•  PERVASIVNESS  AND  INSIDIOUSNESS  OF  THE  PROBLEM  -  The 
pervasive  and  insidious  nature  of  this  problem  make  it  extremely  difficult  to 
find  all  occurrences  of  the  problem.  Date  variables  can  be  named  anything, 
which  makes  it  extremely  difficult  for  tools  or  humans  to  find  every  instance 
to  evaluate. 

To  quote  from  the  Newsweek  article  Even  the  most  diligent  companies 
don’t  have  total  confidence  they  can  fix  everything.  Consider  BankBoston, 
the  15th  largest  commercial  bank  in  the  United  States.  To  stop  a  meltdown, 
BankBoston  has  to  probe  60  million  lines  of  code.  The  harder  Bankboston 
works  at  solving  the  problem  -  it  now  has  40  people  working  full  time  on 
it  -  the  more  complicated  it  seems.  Everyday,  when  we  see  something  new 
we  haven’t  thought  about  we  get  additional  angst,  says  Iacino,  who  heads 
up  this  effort.  [Ref.  1] 

Because  of  the  difficulty  in  finding  all  occurrences  of  year  2000  problems, 
organization’s  year  2000  efforts  will  extend  longer  and  cost  more  than  originally 
estimated. 

•  TESTING  -  Testing  will  consume  a  major  part  of  the  Year  2000  effort.  Some 
estimates  put  this  effort  at  50%  of  a  Year  2000  effort.  Validating  the  results  of 
Year  2000  efforts  is  by  far  the  greatest  technical  challenge  faced  by  Year  2000 
projects.  Multiple  levels  of  tests  will  be  required  for  virtually  every 
application  within  an  organization.  At  a  minimum,  these  tests  must  certify  the 
compliance  of  applications  that  already  handle  century  dates.  Year  2000  dates 
can  appear  in  virtually  all  components  of  an  application,  necessitating  full 
integration  and  system  testing  to  ensure  the  correctness  of  those  changes. 
Testing  does  not  stop  at  the  application’s  boundaries,  interfaces  between 
applications  also  require  verification.  This  level  of  testing  will  be  required  for 
all  of  an  organizations  applications.  This  testing  effort  can  be  aided  through 
the  use  of  tools  designed  to  test  for  Year  2000  compliance.  It  is  important  to 
specify  Year  2000  compliance  criteria.  It  will  also  be  necessary  to  ensure  that 
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the  testing  environment  and  testing  tools  are  year  2000  compliant,  as  they  are 
also  susceptible  to  year  2000  problems.  Testing  organizations  will  have  to 
deal  with  multiple  environments  and  languages  and  may  be  unable,  in  many 
cases,  to  test  on  existing  systems  due  to  problems  with  licensing  expiration 
dates  and  file  structures.  If  dates  are  advanced,  product  licenses  may  expire 
which  will  require  reloading  of  the  effected  products  after  obtaining  the  proper 
permissions  from  the  vendor.  Because  of  these  problems  new  test 
environments  may  need  to  be  established. 

AWARENESS  PHASE  -  The  Awareness  phase  consumes  a  much  larger 
portion  of  the  Year  2000  effort  than  usually  occurs  with  normal  development 
efforts.  This  is  in  large  part  due  to  the  scope  of  the  problem  potentially 
impacting  the  entire  organization  as  well  as  the  reluctance  of  upper 
management  to  accept  the  fact  they  are  going  to  have  to  dedicate  major 
company  resources  to  resolving  a  problem  which  will  not  add  any  new 
capability  to  the  existing  systems.  There  is  traditionally  no  corresponding 
phase  in  current  parametric  models  nor  historical  data  on  this  type  of 
development  or  maintenance. 

ASSESSMENT  PHASE  -  The  Assessment  phase  is  another  phase  not  usually 

in  normal  systems  development.  In  normal  development  efforts,  it  is  not 

required  that  an  inventory  of  all  software  systems  in  the  organization  be 

established  nor  that  all  COTS  vendors  be  required  to  show  compliance  of  their 

products.  Getting  personnel  to  support  obtaining  this  information  is  extremely 

difficult  as  it  normally  competes  with  their  regular  efforts. 

INTERFACES  -  Interfaces  are  another  major  concern  with  the  Year  2000 

problem.  Many  systems  are  connected  to  some  number  of  other  systems. 

This  interconnectivity  revolves  around  data  that  is  passed  and  shared  among 

systems.  This  is  especially  true  of  the  non-AIS  systems  comprising  the 

majority  of  the  SPAWAR  inventory.  Another  aspect  of  the  year  2000  interface 

problem,  is  the  requirement  to  coordinate  changes  to  interfaces  among  all 

interfacing  systems.  Coordination  between  systems  will  be  critical  and  filters, 
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bridges,  and  safety  gates  may  have  to  be  built  at  those  interfaces  until  both 
systems  have  corrected  any  problems  and  can  again  exchange  data  that  is 
acceptable  by  both  systems. 

Margaret  Powell  the  DoN  Year  2000  Action  Officer  states  “Of  particular  concern 
is  the  synchronization  of  system  upgrades  so  we  do  not  have  the  disconnect  when 
the  system  at  one  end  of  the  interface  has  corrected  its  year  2000  problems  and 
the  system  at  the  other  end  has  not”. 

If  systems  do  not  coordinate  there  year  2000  interface  upgrades  efforts  they  will 
just  be  passing  the  problem  to  another  system  they  interface  with. 

•  LEGACY  SYSTEMS  -  Most  data  processing  installations  contain  programs  in 
their  libraries  which  are  no  longer  maintained.  They  continue  to  ran  without 
problem,  but  cannot  be  modified  either  because  no  one  remains  with  any 
expertise  with  the  language,  program,  or  in  the  worst  case,  because  the  source 
code  used  to  create  them  has  been  lost.  In  a  normal  environment  these 
programs  can  run  for  years  if  they  don’t  need  changing  and  don’t  stop 
working.  But  because  of  the  Year  2000  issue  they  must  be  disassembled  and 
examined  to  see  if  they  contain  code  which  operates  on  dates.  There  is  no  easy 
way  to  do  this. 

•  DOCUMENTATION  -  The  year  2000  problem,  unlike  normal  program 
enhancements,  requires  very  few  documentation  changes.  This  will  reduce 
effort  in  this  area  of  the  year  2000  effort  but  will  also  make  it  difficult  to  use 
some  of  the  parametric  models  which  were  based  on  historical  projects  that 
have  required  a  certain  amount  of  documentation. 

•  COTS  -  All  vendors  who  provide  the  organization  with  software  will  have  to 
be  contacted  about  their  products  year  2000  compliance  status  and  plans  to 
bring  them  to  compliance.  This  will  require  the  procurement  and  integration 
of  the  various  product  upgrades.  This  also  requires  an  organization’s 
acquisition  personnel  to  become  involved  in  ensuring  vendors  are 
contractually  responsible. 
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•  ERROR  INJECTION  -  Bad  fixes  are  generally  not  taken  into  account  in 
normal  cost  models.  Year  2000  efforts  are  expected  to  introduce  more  bad 
fixes  than  under  normal  development  efforts. 

According  to  Ref.  5  ordinary  maintenance  of  defect  repairs  in  the  U.S.  is 
accompanied  by  about  a  7%  defect  injection  rate,  i.e.,  about  7  percent  of 
defect  repairs  accidentally  introduce  a  new  defect.  Year  2000  problems 
compound  this  effect  because  many  of  the  programs  are  old  and  poorly 
documented,  and  written  in  antiquated  languages  with  few  current  expert 
programmers.  This  increases  this  percentage  to  -10%,  which  means  that  year 
2000  repairs  may  string  out  for  months  after  the  first  wave  of  initial  repairs. 
Unfortunately  bad  fixes  are  usually  not  considered  in  year  2000  budgets  and 
may  also  be  left  out  of  the  contracts,  which  are  anticipated  to  result  in  a  10% 
overrun.  Ref.  5 

•  HARDWARE  PURCHASES  -  It  is  expected  that  hardware  purchases  will 
increase  to  compensate  for  lost  performance  due  to  Year  2000  fixes.  It  has 
been  predicted  in  the  literature  that  Year  2000  repairs  are  likely  to  seriously 
impact  the  performance  of  many  of  the  mainframe  systems. 


“Estimates  of  performance  degradation  range  from  10  -  35%  loss  in  data 
throughput.”  [Ref.  5] 

•  This  would  prove  to  be  extremely  detrimental  to  the  majority  of  mainframe 
applications.  The  result  of  this  performance  degradation  will  either  be 
procurement  of  additional  hardware  to  compensate  for  the  loss  or  software 
optimization.  Capers  Jones  estimates  that  hardware  upgrades  could  add  an 
additional  25  percent  to  the  year  2000  effort.  It  is  also  expected  that  a  large 
number  of  personnel  computers  will  fail  at  the  year  2000  rollover  due  to  date 
problems  with  their  BIOS.  Replacement  or  repair  of  these  units  will  also  add 
to  the  hardware  upgrade  effort  at  most  organizations. 

•  SOFTWARE  OPTIMIZATION  -  It  is  expected  that  software  efforts  will  be 
increased  in  order  to  increase  system  performance  after  changes  are  made  to 
correct  Year  2000  problems.  It  is  anticipated  that  Year  2000  corrections  will 
seriously  impact  many  main  frame  systems  that  have  been  tuned  to  obtain 
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maximum  performance  from  their  existing  hardware  environment. 

“It  has  been  estimated  that  this  effort  could  add  an  additional  10%  to  the 
Year  2000  effort.”  [Ref.  5] 

•  TOOLS  -  The  year  2000  problem  is  an  extraordinarily  complex,  pervasive 
maintenance  task.  Without  sufficient  automated  tool  support,  it  is  a  task  that 
will  quickly  become  unmanageable  and  unnecessarily  expensive,  no  matter 
how  well  it  is  managed. 

Peter  de  Jager  states  “If  you’re  not  changing  code  by  November  of 
1997,  you  will  not  get  this  thing  done  on  time,  its  that  simple.” 

And  that  is  based  on  experienced  users  with  sophisticated  tools.  The  start  date  for 
being  able  to  complete  this  effort  with  average  personnel  and  no  tools  was  last 
year.  Aside  from  their  scale,  the  activities  performed  for  Year  2000  migration 
projects  are  fundamentally  the  same  as  those  performed  for  routine  software 
maintenance.  Thus  the  tools  used  for  maintenance  can  be  applied  to  year  2000 
projects.  New  software  tools  have  been  created  specifically  to  support  century 
compliance  projects.  These  tools  are  generally  not  reusable  for  routine 
maintenance  tasks  but  are  optimized  for  year  2000  tasks.  Other  year  2000  tools 
are  owned  by  conversion  vendors  and  are  installed  at  their  off  site  conversion 
facilities.  Organizations  do  not  use  these  tools  directly,  but  receive  their  benefits 
when  they  out  source  their  applications  to  the  conversion  vendor.  As 
organizations  plan  their  Year  2000  projects,  this  range  of  tool  categories  offers 
three  distinct  tool  strategies:  off  site  conversions,  year  2000  specific  tools,  and 
maintenance  tools.  Unfortunately,  most  maintenance  tools  are  not  sophisticated 
enough  to  handle  year  2000  maintenance  on  complex,  mission  critical  systems. 

For  example,  virtually  no  tool  support  exists  for  some  languages  used  in  mission- 
critical  systems,  including  Jovial,  CMS-2,  ADA,  C,  or  C++,  and  dialects  of 
assembly  language.  Few  tools  offer  automated  support  for  correction  and  testing, 
the  two  phases  in  which  most  errors  are  introduced.  In  the  DOD  environment,  a 
deliberate  emphasis  on  next  generation  language  tools  has  been  at  the  expense  of 
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promoting  better  maintenance  tools  for  older  languages.  Yet  at  least  80  percent  of 
existing  applications  are  maintained  in  various  legacy  languages  for  which 
maintenance  tool  support  is  sorely  needed.  The  quality  and  level  of  automation 
for  Year  2000  software  tools  is  increasing  daily.  While  the  degree  of  automation 
will  increase  over  the  next  few  years,  tool  coverage  will  be  restricted  to  the  most 
common  languages  and  environments.  Automation  covers  only  the  most  mundane 
portions  of  a  year  2000  effort,  i.e.  code  translation.  Project  management  issues, 
coordination  of  interfaces,  software  package  upgrades,  data  conversion,  testing, 
and  numerous  other  time  consuming  activities  will  not  be  automated.  [Ref.  17] 
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IV.  SPACE  AND  NAVAL  WARFARE  SYSTEM  CENTER  (SPA WAR) 

YEAR  2000  STATUS 


A.  SPA  WAR  YEAR  2000  POA&M 

Until  the  extent  of  the  problem  is  known,  the  operational  risk  DoN  might 
encounter  at  the  change  of  century  is  unknown.  What  is  known  is  that  by  the  year  2000,  if 
the  problem  is  not  addressed,  an  undetermined  number  of  current  systems  will  begin  to 
fail  -  some  systems  even  earlier.  Therefore,  it  is  considered  critical  that  the  DoN  execute 
a  well  thought  out  approach  to  determine  the  extent  of  the  problem  and  cost  of 
corrective  action.  The  approach  selected  to  achieve  this  goal  is  the  DOD  five  phased 
approach,  which  has  been  adopted  by  all  the  services.  This  case  study  focuses  on  one 
organization  within  the  DoN,  SPAWAR,  and  specifically  how  SPAWAR  is 
implementing  the  Assessment  Phase  of  the  DOD  Five  Phased  plan. 

The  Assessment  Phase  is  considered  the  most  critical  phase  by  Year  2000  experts 
because  it  allows  management  to  scope  the  problem,  develop  cost  estimates,  assess  risks 
and  determine  priorities,  establish  policies  and  procedures,  and  make  the  necessary 
decisions  on  the  most  viable  approach  to  the  Year  2000  resolution.  The  first  step  in  the 
SPAWAR  Assessment  phase  was  to  establish  a  SPAWAR  Plan  of  Action  &  Milestones 
(POA&M)  in  June  1996.  Because  this  POA&M  was  developed  before  receipt  of  the 
DOD  Management  Plan  and  the  DoN  Year  2000  Action  Plan,  it  is  currently  being 
updated  to  be  in  concert  with  these  two  upper  level  documents.  The  following  are 
milestones  in  support  of  implementing  the  SPAWAR  Year  2000  POA&M  and  this 
thesis: 

•  June  1996:  received  SPAWAR  POA&M  requiring  surveys  of  all  SPAWAR 
systems 

•  July  1996:  Quicklook  Surveys  were  collected  and  submitted  to  SPAWAR,  or 
other  sponsors  as  applicable.  Three  hundred  and  three  NRaD  systems  logged, 
98  identified  as  SPAWAR  systems,  but  not  all  sponsors  identified  so  number 
of  SPAWAR  systems  could  have  been  higher 

•  July  1996:  NCCOSC,  SPAWAR’s  RDT&E  laboratory,  tried  to  implement 
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survey  on  the  web.  The  Commanding  Officer  felt  the  survey  was  too  difficult, 
causing  undue  burden  on  those  being  asked  to  fill  it  out,  and  asked  SPAWAR 
to  reduce  the  reporting  requirement.  SPAWAR  could  not  comply  with  request 
as  the  requirements  were  being  levied  by  organizations  above  SPAWAR 

•  September  1996:  NCCOSC  conducts  Year  2000  Workshop  and  Tool  Fair 

•  November  1996:  Impact  Surveys  (updated  Quicklook  Survey)  submitted  to 
SPAWAR 

•  November  1996:  SPAWAR  developed  the  Year  2000  Assessment  Checklist 
(Appendix.  C).  According  to  MITRE  Corp.,  a  realistic  assessment  of  a  project 
to  determine  if  it  is  impacted  by  Year  2000  should  take  1-2  weeks.  The 
Assessment  Checklist  was  intended  to  assist  project  managers  in  doing  a 
preliminary,  and  rapid,  assessment  of  their  systems  to  be  able  to  answer  the 
data  calls  without  having  to  go  through  the  1-2  week  assessment  first.  Since 
then,  the  Assessment  Checklist  has  become  a  mandatory  report  for  all 
SPAWAR  systems  based  on  a  requirement  in  the  DOD  Year  2000 
Management  Plan  to  have  such  a  document 

•  January  1997:  Data  call  from  OSD/C3I  requiring  the  number  of  ELOC 
(executable  lines  of  code)  for  every  SPAWAR  system.  The  data  call  required 
that  for  AIS  systems,  a  cost  estimate  of  $1.10  for  eveiy  ELOC  be  used  and  for 
other  systems  (weapon,  embedded,  mission  critical)  a  cost  of  $8.00  for  every 
ELOC  be  used 

•  January  1997:  Based  on  the  multiple,  and  constant,  data  calls  for  which  the 
Impact  Survey  was  inadequate,  the  SPAWAR  Systems  Inventory  form 
(Appendix.  B)  was  developed  to  collect  data  with  which  to  answer  the  various 
calls  without  having  to  go  back  to  the  system  project  managers  each  time.  The 
future  intent  is  to  have  an  automated  version  of  this  inventory  form  which 
project  managers  can  keep  updated  at  their  convenience  and  from  which 
SPAWAR  can  pull  answers  to  most  future  data  calls 

•  March  1997:  Admiral  Wagner,  Commander  of  SPAWAR  calls  for  Program 


44 


Reviews  on  all  SPAWAR  systems.  Each  Program  Directorate  (PD)  was 
required  to  participate  by  attending  the  review,  presenting  Year  2000  status  on 
all  systems  in  the  directorate,  turning  in  signed  Assessment  Checklists  and 
SPAWAR  System  Inventory  forms.  Two  PD’s  accepted  a  SPAWAR  offer  to 
pay  for  half  of  a  full  2  week  assessment  facilitated  by  MITRE. 

•  April  1997  to  present:  tracking  SPAWAR  Assessment  Checklists  and  System 
Inventory  forms 

•  July  25,  1997:  Baseline  date  for  data  used  in  this  thesis  (Note:  Author 
understands  the  dynamic  nature  of  this  SPAWAR  effort  and  realizes  that  this 
data  has  changed  since  this  baseline  date) 

1.  SPAWAR  Systems  Inventory 

The  first  major  step  in  the  SPAWAR  POA&M  was  to  compile  an  inventory  of  all 
computer  based  systems  within  the  organization.  As  simple  as  this  may  sound, 
determining  which  systems  were  in  the  SPAWAR  Systems  Inventory  proved  to  be 
extremely  difficult. 

The  first  problem  was  to  provide  a  concise  definition  of  what  constitutes  a  system. 
In  keeping  with  the  philosophy  of  centralized  management  and  decentralized  execution, 
the  initial  approach  taken  by  DoN  was  to  allow  each  of  the  reporting  organizations  the 
flexibility  to  define  what  a  system  was  composed  of  for  their  respective  organization. 
Unfortunately  this  approach  has  produced  inconsistent  definitions,  making  comparison  of 
data  between  organizations  difficult.  Even  within  an  organization  such  as  SPAWAR, 
obtaining  and  applying  a  concise  definition  of  a  system  has  proven  difficult.  The  current 
definition  of  a  system  being  used  by  SPAWAR  is, 

A  computer  system  includes  all  software,  hardware  and  firmware 
information  technology  components  that  are  operational,  under  development, 
under  test,  or  even  in  the  planning  phase.  This  includes  COTS,  GOTS  systems 
and  components,  and  unfunded  legacy  systems  which  can  be  either  a 
hardware-software  system  or  a  software  system.  A  radar  system  is  an  example 
of  a  hardware-software  system.  A  personnel  or  payroll  system  is  an  example 
of  a  software  system. 

Because  of  the  difficulty  in  clearly  defining  what  a  system  is  composed  of, 
fluctuations  in  the  number  of  systems  reported  occur  as  products  are  variously  included  or 
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excluded  within  a  system  during  subsequent  reporting  periods.  This  problem  is 
compounded  in  the  DOD  with  the  integration  of  multiple  systems  into  systems  of 
systems.  Where  one  system  stops  and  another  starts  is  not  always  easily  defined  and  can 
be  somewhat  arbitrary. 

The  second  major  problem  encountered  was  that  there  was  no  central  library 
containing  a  listing  of  all  the  systems  supported  by  the  SPAWAR  organization.  An 
extensive  effort  was  required  by  each  of  the  directorates  within  SPAWAR  to  identify  the 
various  systems  supported,  and  determine  the  department  responsible  for  that  system. 
This  effort  is  ongoing  with  new  systems  continuing  to  be  identified  and  previously 
identified  systems  being  merged  or  separated  creating  new  systems.  This  inability  to 
identify  all  the  systems  composing  the  SPAWAR  inventory  resulted  in  a  protracted 
Assessment  phase.  The  extension  of  this  phase  will  result  in  an  increase  in  Year  2000 
costs  and  a  reduced  time  frame  in  which  to  complete  the  other  phases  of  the  Year  2000 
effort. 

2.  SPAWAR  Systems  Assessment 

Once  the  inventory  was  established,  the  next  step  was  to  conduct  a  Year  2000 
impact  assessment  for  each  of  those  systems.  In  support  of  the  Assessment  phase,  two 
separate  forms  were  provided  to  each  of  the  systems  project  managers:  the  Year  2000 
Assessment  Checklist  and  the  SPAWAR  Systems  Inventory  (sometimes  referred  to  as  the 
SPAWAR  Questionnaire).  The  Year  2000  Assessment  Checklist  was  designed  to  be  a 
“thought  provoker”  for  development  and  maintenance  personnel  to  use  in  their  initial 
assessment  of  a  systems  year  2000  compliance.  A  sample  Year  2000  Assessment 
Checklist  is  provided  in  Appendix  C.  The  SPAWAR  Systems  Inventory  (Appendix  B) 
was  the  result  of  a  detailed  survey  of  the  current  literature  and  web  sites  dealing  with  this 
type  of  activity  and  a  compilation  of  all  data  requested  to  be  reported  to  date.  The 
SPAWAR  Systems  Inventory  was  designed  to  1)  provide  a  single  data  call  that  the 
projects  could  respond  to  and  update  that  would  answer  the  many  requests  for 
information  that  were  coming  to  the  projects  at  an  ever  increasing  pace  and  2)  provide 
information  on  Year  2000  costing  parameters  that  could  be  used  for  this  thesis  and  by 

others  for  later  analysis.  This  inventory  form  was  distributed  along  with  a  Year  2000 
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Assessment  Checklist  to  each  of  the  program  managers  within  SPAWAR,  who  then 
distributed  them  to  each  of  their  project  managers.  The  completed  forms  were  then  to  be 
returned  and  the  data  entered  into  a  SPAWAR  database  with  a  subset  of  the  information 
going  into  the  DOD  designated  Year  2000  database.  This  information  was  tracked  and 
status  provided  to  upper  management  several  times  a  month.  SPAWAR  Year  2000  status 
is  provided  in  Appendix  D. 

The  initial  SPAWAR  Year  2000  status  review  was  held  in  March  1997,  with 
upper  management,  to  determine  the  Year  2000  status  of  the  SPAWAR  organization. 
This  status  is  updated  on  a  quarterly  basis. 

a.  SPA  WAR  Systems  Year  2000  Reporting  Status 
The  current  status  of  the  effort  for  each  of  the  reporting  systems  is  shown 
in  Figure  3.  The  data  presented  in  Figure  3  is  current  as  of  July  25,  1997,  the  baseline  date 
for  this  thesis.  (Note:  Much  activity  continues  within  SPAWAR  and  statistics  presented 
in  this  thesis  are  changing  continually)  As  Figure  3  shows,  10%  of  the  systems  have  not 
completed  assessments,  this  phase  was  scheduled  for  completion  in  June  1997.  Another 
15%  of  the  systems  have  not  turned  in  signed  Year  2000  Assessment  Checklists.  These 
checklists  were  to  be  signed  by  each  of  the  systems  project  managers  indicating  that  they 
had  completed  the  items  on  the  Year  2000  checklist  and  that  the  information  was 
accurate.  13%  of  the  systems  have  not  submitted  the  detailed  SPAWAR  Systems 
Inventory  forms.  A  major  problem  in  this  phase  was  the  difficulty  in  getting  the  forms 
completed  and  returned  even  though  mandated.  The  SPAWAR  office  collecting  the  data 
was  viewed  as  the  problem  and  the  proverbial  “shoot  the  messenger”  scenario  ensued. 
Getting  timely,  complete  and  reliable  responses  from  the  projects  has  been  one  of  the 
most  time  consuming  and  difficult  parts  of  the  Assessment  effort  so  far.  Figure  4  shows 
the  timeline  of  responses  for  the  requested  Year  2000  data  from  each  of  the  program 
directorates.  This  data  was  originally  requested  in  March  1997,  and  this  phase  has  still  not 
been  completed.  The  data  illustrates  the  slow  return  of  the  surveys  and  questionnaires 
which  has  prolonged  the  assessment  phase  and  made  it  difficult  for  upper  management  to 
get  a  handle  on  the  scope  of  the  Year  2000  problem.  In  addition  to  the  difficulty 

identifying  the  systems  in  the  inventory,  there  has  been  a  reluctance  to  take  this  problem 
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seriously.  Many  program/project  managers  do  not  fully  understand  all  the  possible 
implications  of  the  Year  2000  problem  and  therefore  have  been  quick  to  state  that  their 
projects  have  no  Year  2000  problem.  This  is  partially  due  to  the  fact  that  the  Year  2000 
effort  within  the  organization  is  unfunded  causing  any  year  2000  expenditures  to  come 
out  of  project  resources  that  are  currently  allocated  for  other  efforts.  Until  the  DOD 
determines  that  this  is  a  problem  sufficient  enough  to  warrant  additional  funding, 
schedule  relief,  or  reduction  of  requirements,  we  will  continue  to  receive  data  that  is  of 
questionable  quality.  As  shown  in  Figure  3,  160  systems  have  been  identified  within  the 
SPAWAR  organization.  As  indicated,  this  number  has  been  changing  constantly  as  new 
systems  are  entered  and  old  systems  are  determined  to  be  composed  of  multiple  systems. 
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Total 

Systems 

Assessment  Not 
Complete 

Signed 

Checklists 

Needed 

Inventory 

Forms 

Needed 

NRaD 

2 

2 

2 

2 

PD13 

3 

0 

0 

0 

PMW-151 

27 

0 

6 

1 

PMW-152 

9 

0 

0 

0 

PMW-161 

2 

0 

0 

0 

PMW-162 

2 

0 

0 

0 

P  MW- 163 

11 

0 

0 

0 

PMW-171 

5 

0 

0 

0 

P  MW- 173 

15 

0 

0 

0 

PMW-176 

48 

7  • 

20 

6 

PMW-181 

3 

1 

1 

1 

PMW-182 

2 

0 

0 

0 

P  MW- 183 

1 

0 

0 

0 

PMW-185 

3 

1 

0 

1 

PMW-187 

16 

7 

2 

2 

PEO-SCS 

8 

0 

0 

1 

SPAWAR 

05/07 

3 

0 

2 

2 

Totals 

160 

18 

33 

16 

Figure  3.  SPAWAR  System  Inventory  Response  Status 
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Figure  4.  SPA  WAR  Year  2000  Reporting  History 


b.  SPA  WAR  Systems  Year  2000  Problem  Status 

Figure  5  SPAWAR  Y2K  Problem  Status,  shows  the  current  data  regarding  the  year  2000 
status  of  the  SPAWAR  systems. 

•  Status  Code  A  “No  Y2K  Problem”,  shows  the  number  of  systems  reporting  that  they  have 
no  Year  2000  problem.  There  has  been  a  slight  decrease  in  the  number  of  systems  reporting 
this  status.  This  figure  compares  the  data  from  the  last  data  call  and  this  the  most  recent. 
Currently  approximately  25%  of  the  systems  are  reporting  no  Year  2000  problem. 

•  Status  code  B  “Fix  In  Place”,  indicates  that  few  of  the  systems  have  actually  had  time  to 
implement  Year  2000  corrective  changes  into  their  systems.  This  value  will  obviously 
increase  as  more  systems  complete  maintenance  efforts. 

•  Status  Codes  C  “Fix  in  Next  Release”,  has  increased  significantly  as  more  systems  have 
determined  they  have  Year  2000  problems  and  are  factoring  this  in  to  their  upgrade  schedule. 

•  Status  Code  D  “Fix  In  Development”  has  also  increased  dramatically,  again  due  to  the  fact 
that  programs  have  identified  year  2000  problems  and  because  of  the  increased  priority  by 
upper  management 

•  Status  Code  E  “  Will  Fix  Before  Y2K”  this  value  has  decreased,  as  program  managers  have 
had  more  time  to  evaluate  their  options,  decisions  are  being  made  to  incorporate  fixes  into 
current  development  efforts,  or  not  to  fix,  but  retire  the  system. 

•  Status  Code  F  “Dependent  on  TOOLS”,  none  of  the  systems  reported  that  their  Year  2000 
effort  was  dependent  on  tool  availability. 
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•  Status  Code  G  “Dependent  on  COTS”,  systems  reporting  this  status  have  increased 
significantly.  This  is  a  result  of  the  realization  that  COTS  products  are  not  exempt  from  this 
problem.  The  number  of  systems  with  a  status  code  indicating  their  Year  2000  fix  is 
dependent  on  COTS  should  continue  to  rise  as  more  vendors/users  identify  problems  with 
the  various  COTS  products.  Vendors  have  been  reluctant  to  provide  this  information. 
Vendors  are  also  very  reluctant  to  certify  that  their  products  are  Year  2000  compliant  due  to 
litigation  issues  making  it  very  difficult  to  determine  if  their  products  are  in  fact  Year  2000 
compliant. 

•  Status  Code  H  “Will  Not  Fix”,  the  number  of  systems  reporting  this  status  has  increased 
slightly.  As  program  managers  evaluate  their  options  more  systems  may  choose  this  option, 
because  the  window  during  which  the  problem  will  occur  is  minimal  and  there  are 
acceptable  workarounds. 

•  Status  Code  I  “To  be  Terminated”,  systems  reporting  this  status  have  increased  slightly. 
This  value  may  increase  as  more  project  managers  determine  the  magnitude  of  the  Year 
2000  effort  and  other  options  become  cost  effective. 

•  Status  Code  J  “Under  Assessment”,  systems  reporting  this  status  continue  to  decrease  but  at 
a  slow  rate.  This  is  a  problem  as  these  systems  have  not  completed  assessment  prior  to  the 
June  1997  date  for  completion  of  this  phase. 

•  Status  Code  K  “Acquisition/Development”,  systems  reporting  this  status  has  increased 
significantly.  This  was  because  this  was  a  recently  created  category  created  to  accommodate 
these  systems. 

c.  SPAWAR  Systems  Year 2000  Phase  Status 

Figure  6  “SPAWAR  Systems  by  Phase”  shows  the  current  status  of  the  SPAWAR 
systems  by  phase.  All  systems  within  the  organization  have  moved  out  of  the  Awareness  phase. 
Seventeen  systems  are  currently  in  the  assessment  phase  which  according  to  the  current  SPAWAR 
POA&M  should  have  been  completed  by  June  1997.  Eighty  seven  systems  are  currently  in  the 
Renovation  phase.  One  system  is  currently  in  the  Validation  phase  and  sixty  eight  systems  are  in  the 
Implementation  phase  (Note:  the  Implementation  phase  includes  status  codes  A,  B,  H,  and  I).  It  is 
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significant  that  only  one  system  is  in  the  validation  phase.  It  may  indicate  a  lack  of  understanding  of  the 
testing  required  for  Year  2000  and  also  the  difficulty  establishing  test  environments  for  Year  2000 
testing,  which  may  become  a  growing  issue  as  more  systems  approach  this  phase. 


Phase 

Awareness 

0 

Assessment 

18 

Renovation 

81 

Validation 

0 

Implementation 

61 

Total 

160 

As  of  July  25, 1997 


Figure  6.  SPA  WAR  Systems  by  Phase 
d.  SPAWAR  Systems  Inventory  Results 

The  following  are  fields  included  in  the  SPAWAR  System  Inventory  because  of  their 
potential  impact  on  Year  2000  costs.  SPAWAR  System  Inventory  results  are  provided  in  Appendix  E. 
(Note:  the  following  data  is  based  on  151  systems  responding  to  these  questions  on  the  SPAWAR 
Systems  Inventory  form.  Not  all  systems  responded  to  all  questions.) 

•  B4  Software  Package  Vendor  -  The  survey  listed  43  different  software  package  vendors. 
The  greater  the  number  of  vendors  the  greater  the  costs  associated  with  having  to  assess 
each  vendors  package  for  compliance.  If  vendors  are  found  to  be  non  compliant,  then 
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having  to  deal  with  multiple  vendors  can  create  higher  procurement  costs.  Finding  and 
procuring  new  compliant  vendor  packages  and/or  design  and  implement  a  work  around 
increases  people  and  time  resources. 

•  B5  Software  Package  Upgrade  -  Is  a  software  package  upgrade  required  for  Year  2000?  66 
systems  responded  no,  46  responded  yes.  Upgrading  software  packages  will  effect  a  large 
number  of  SPAWAR  systems  and  increase  Year  2000  costs.  Contingency  plans  in  case 
upgrade  is  not  available  in  time  are  required. 

•  B7  Programming  Language  -  Very  few  of  the  SPAWAR  systems  are  written  in  COBOL  or 
any  of  the  other  languages  for  which  the  majority  of  Year  2000  tools  have  been  developed. 
Because  of  this,  there  will  be  a  greater  dependence  on  manual  efforts  to  find  and  fix  Year 
2000  problems.  This  will  increase  the  Year  2000  costs  for  the  organization  and  may  prolong 
each  of  the  different  phases. 

•  B8  Compiler  Availability  -  108  systems  reported  compilers  were  available,  9  systems 
reported  compilers  were  not  available.  The  majority  of  the  SPAWAR  systems  have 
compilers  available  which  should  reduce  the  Year  2000  effort.  For  those  systems  lacking 
compilers  further  analysis  should  be  done  to  determine  systems  criticality  and  compliance 
options. 

•  B14  Documentation  -  Is  requirements  and  design  documentation  available?  93  systems 
reported  documentation  is  available,  18  reported  documentation  was  not  available.  The 
majority  of  systems  indicated  they  have  documentation  available  which  should  reduce  the 
overall  cost  of  SPAWAR  Year  2000  compliance.  Those  systems  not  having  documentation 
available  will  have  a  higher  Year  2000  costs  because  this  will  increase  the  difficulty  in 
understanding  and  analyzing  the  system  for  year  2000  problems. 

•  B15  Source  Code  Availability  -  106  systems  reported  source  code  was  available,  with  14 
reporting  source  code  would  not  be  available.  Not  having  source  code  available  will 
seriously  impact  a  systems  options  in  dealing  with  Year  2000  problems.  Without  the  source 
code  you  will  not  be  able  to  go  in  and  analyze  and  correct  the  code.  You  must  then  either 
come  up  with  a  method  to  recreate  the  code  or  create  solutions  external  to  the  system.  The 
majority  of  SPAWAR  systems  have  the  source  code  available  which  will  reduce  the  overall 
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Year  2000  costs.  Those  systems  lacking  source  code  will  have  to  be  further  analyzed  to 
determine  which  options  are  available  and  most  appropriate.  This  could  potentially  increase 
Year  2000  costs  for  these  systems. 

•  B 17  Date  Formats  -  Over  90%  of  the  systems  reported  high  or  medium  consistency  within 
the  system  of  a  standard  date  format.  This  should  reduce  the  effort  required  to  find  and 
correct  Year  2000  problems  in  these  systems.  This  should  reduce  the  overall  Year  2000 
costs. 

•  B19  Two-digit  year  problem  -  66  systems  reported  having  this  problem,  49  did  not  have 
this  problem.  Systems  will  have  to  make  decision  as  to  which  option  is  most  appropriate  for 
their  situation  i.e.  sliding  window,  four  digit  year  etc. 

•  B20  Six-digit  date  problem  -  39  systems  reported  having  this  problem,  76  did  not  have  this 
problem.  Systems  will  have  to  make  decision  as  to  which  option  is  most  appropriate  for 
their  situation  i.e.  sliding  window,  four  digit  year  etc. 

•  B21  Leap  year  errors  -  17  systems  reported  having  this  problem,  101  did  not  have  this 
problem.  This  is  a  minor  change  which  should  not  seriously  impact  year  2000  cost. 

•  B22  Inaccurate  data  calculations  -  38  systems  reported  having  this  problem,  83  did  not 
have  this  problem.  It  is  difficult  to  find  all  the  instances  of  this  problem.  This  will  increase 
analysis  and  testing  efforts  and  require  multiple  cycles  to  resolve  all  instances.  This  problem 
will  increase  the  overall  Year  2000  costs  for  these  systems. 

•  B23  On-Line  screen  changes  -  37  systems  reported  having  this  problem,  82  did  not  have 
this  problem.  Systems  will  have  to  make  decision  as  to  which  option  is  most  appropriate  for 
their  situation.  If  room  is  available  on  the  screen  these  changes  could  be  minor  If  room  is 
not  available  on  the  screen  more  creative  solutions  will  be  required  that  will  increase  costs. 

•  B24  Report  form  changes  -  30  systems  reported  having  this  problem,  87  did  not  have  this 
problem.  Systems  will  have  to  make  decision  as  to  which  option  is  most  appropriate  for 
their  situation.  If  room  is  available  on  the  report  these  changes  could  be  minor.  If  room  is 
not  available  on  the  report  more  creative  solutions  will  be  required  that  will  increase  costs. 

•  B26  Operating  System  Vendors  -  The  systems  reported  24  different  operating  system 
vendors.  This  will  increase  the  overall  Year  2000  cost  due  to  the  fact  multiple  vendors  must 
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be  assessed  for  compliance  and  if  problems  are  found  multiple  solutions  must  be  dealt  with. 

•  B27  Operating  System  Upgrade  -  38  systems  reported  having  to  upgrade  their  operating 
systems,  62  did  not  having  to  upgrade  their  operating  systems.  This  will  significantly 
increase  the  overall  Year  2000  cost  for  these  systems.  Integrating  new  operating  systems 
can  be  quite  time  consuming,  depending  on  the  solutions  provided  by  the  vendors. 

•  B34  DBMS  Upgrade  -  4  systems  reported  having  this  problem,  48  did  not  have  this 
problem.  The  majority  of  the  SPAWAR  systems  did  not  require  this  effort  so  this  should 
not  be  a  major  cost  driver. 

•  D5  Hardware  Manufacturer  -  The  survey  listed  46  different  hardware  package  vendors.  The 
greater  the  number  of  vendors  the  greater  the  costs  associated  with  having  to  assess  each 
vendor’s  package  for  compliance.  If  vendors  are  found  to  be  non  compliant,  then  having  to 
deal  with  multiple  vendors  can  create  higher  procurement  costs. 

•  D6  Hardware  Upgrade  -  8  systems  reported  requiring  a  hardware  upgrade,  100  systems  did 
not  require  a  hardware  upgrade.  The  majority  of  the  SPAWAR  systems  did  not  require  this 
effort  so  this  should  not  be  a  major  cost  driver. 

•  D8  BIOS  Compliance  -  72  systems  reported  BIOS  compliance,  14  systems  reported  not 
being  BIOS  compliant.  The  majority  of  the  SPAWAR  systems  did  not  require  this  effort  so 
this  should  not  be  a  major  cost  driver. 

•  E4  Y2K  Hardware  Platform  Compliance  -  87  systems  reported  that  their  hardware  was 
Y2K  compliant,  7  systems  reported  non-compliance.  The  majority  of  the  SPAWAR  systems 
did  not  require  this  effort  so  this  should  not  be  a  major  cost  driver. 

•  E5  Y2K  Operating  System  Compliance  -  64  systems  reported  compliance,  27  systems 
reported  non-compliance.  This  will  significantly  increase  the  overall  Year  2000  cost  for 
these  systems.  Integrating  new  operating  systems  can  be  quite  time  consuming,  depending 
on  the  solutions  provided  by  the  vendors. 

•  E6  Y2K  System  Application  Compliance  -  61  systems  reported  compliance,  29  systems 
reported  non-compliance.  Depending  on  the  degree  of  non-compliance  and  the  solution 
option  selected  this  will  increase  the  overall  Year  2000  cost  for  these  systems. 

•  E7  Sort  Routine  Compliance  -  59  systems  reported  compliance,  12  systems  reported  non- 
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compliance.  Depending  on  the  degree  of  non-compliance  and  the  solution  option  selected 
this  will  increase  the  overall  Year  2000  cost  for  these  systems. 

•  E8  Backup  Routine  Compliance  -  60  systems  reported  compliance,  8  systems  reported  non- 
compliance.  This  does  not  appear  to  be  a  major  cost  driver  for  the  overall  Year  2000  cost 
for  these  systems. 

•  E9  Archival  Routine  Compliance  -  52  systems  reported  compliance,  6  systems  reported 
non-compliance.  This  does  not  appear  to  be  a  major  cost  driver  for  the  overall  Year  2000 
cost  for  these  systems. 

•  F3  Field  Expansion  -  30  systems  will  use  this  option  to  correct  their  year  2000  problem,  24 
systems  will  not.  Expanding  the  date  field  is  a  time  consuming  effort  which  could  also 
impact  interfacing  systems.  This  will  increase  the  overall  Year  2000  cost  for  these  systems. 

•  F4  Procedural  Code  -  3 1  systems  will  use  this  option  to  correct  their  year  2000  problem,  22 
systems  will  not.  Using  the  procedural  code  option  reduces  the  amount  of  effort  required  in 
correcting  the  Year  2000  problem  because  it  limits  the  amount  of  change  required  to  the 
code  and  databases.  This  will  decrease  the  overall  Year  2000  cost  for  these  systems. 

•  F5  Sliding  Window  -  12  systems  will  use  this  option  to  correct  their  year  2000  problem,  40 
systems  will  not.  Using  the  sliding  window  option  reduces  the  amount  of  effort  required  in 
correcting  the  Year  2000  problem  because  it  reduces  the  amount  of  change  required  to  code 
and  databases.  This  will  decrease  the  overall  Year  2000  cost  for  these  systems. 

•  F7  Tools  to  Find  Y2K  Problems  -  25  systems  will  use  tools  to  find  Year  2000  problems,  30 
systems  will  not.  Using  tools  reduces  the  amount  of  effort  required  in  finding  the  Year  2000 
problem.  This  will  decrease  the  overall  Year  2000  cost  for  these  systems.  Because  30 
systems  are  not  using  tools  this  will  increase  the  SPA  WAR  overall  Year  2000  costs. 

•  F8  Tools  to  Fix  Y2K  Problems  -  8  systems  will  use  this  tools  to  fix  Year  2000  problems, 

45  systems  will  not.  Using  tools  reduces  the  amount  of  effort  required  in  fixing  the  Year 
2000  problem.  This  will  increase  the  overall  Year  2000  cost  for  these  systems.  Because 
only  8  systems  are  using  tools  this  could  increase  the  SPAWAR  overall  Year  2000  costs. 

•  F9  Development  Tool  Availability  -  42  systems  will  use  this  tools  to  assist  in  the  Year 
2000  effort,  8  systems  will  not.  Using  tools  generally  reduces  the  amount  of  effort  required 
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in  resolving  the  Year  2000  problem.  This  will  decrease  the  overall  Year  2000  cost  for  these 
systems. 

•  F10  Application  Expertise  -  47  systems  reported  high  levels  of  expertise,  10  systems 
reported  medium  levels  of  expertise,  and  1  systems  reported  low  levels  of  expertise.  High 
levels  of  application  expertise  will  decrease  the  effort  required  to  find  and  fix  year  2000 
problems.  This  will  decrease  the  overall  Year  2000  cost  for  these  systems. 

•  FI  1  Language  Expertise  -  55  systems  reported  high  levels  of  expertise,  3  systems  reported 
medium  levels  of  expertise,  and  0  systems  reported  low  levels  of  expertise.  High  levels  of 
language  expertise  will  decrease  the  effort  required  to  find  and  fix  year  2000  problems.  This 
will  decrease  the  overall  Year  2000  cost  for  these  systems. 

•  F12  Special  Upgrade  -  12  systems  reported  that  they  would  require  a  special  software 
upgrade  to  correct  Year  2000  problems  outside  of  their  normal  upgrade  schedule,  42 
systems  reported  that  a  special  software  upgrade  would  not  be  required.  For  those  systems 
requiring  a  special  software  upgrade  this  could  significantly  increase  the  overall  cost  of 
Year  2000.  For  those  systems  that  are  able  to  incorporate  the  Year  2000  changes  into  a 
normal  upgrade  cycle  the  costs  will  be  considerably  less. 

•  F14  Technical  Risk  -  6  systems  reported  high  levels  of  risk,  14  systems  reported  medium 
levels  of  risk,  and  37  systems  reported  low  levels  of  risk.  The  majority  the  systems  reported 
low  to  medium  risk  levels,  this  will  tend  to  decrease  the  overall  Year  2000  cost  for  these 
systems. 

•  FI 5  Funding  Resources  Risk  -  15  systems  reported  poor  availability  of  funding,  19  systems 
reported  moderate  availability  of  funding,  and  15  systems  reported  adequate  availability  of 
funding.  Inadequate  funding  will  seriously  impact  the  Year  2000  risk.  A  large  number  of 
systems  reported  poor  to  moderate  availability  of  funding,  this  will  tend  to  increase  the 
overall  Year  2000  risk  for  these  systems  because  it  will  reduce  the  level  of  effort  on  these 
systems  which  will  extend  the  phases  and  impact  the  ability  of  these  systems  to  complete 
this  effort  prior  to  Year  2000. 

•  F16  People  Resource  Risk  - 12  systems  reported  poor  availability  of  personnel  resources, 

13  systems  reported  moderate  availability  of  personnel  resources,  and  31  systems  reported 
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adequate  availability  of  personnel  resources.  Inadequate  personnel  resources  will  seriously 
impact  the  Year  2000  risk.  Approximately  half  of  the  systems  reported  poor  to  moderate 
availability  of  personnel  resources.  This  will  increase  the  overall  Year  2000  risk  for  these 
systems. 

•  F17  Facilities  Resources  Risk  -  9  systems  reported  poor  availability  of  facility  resources,  14 
systems  reported  moderate  availability  of  facility  resources,  and  33  systems  reported 
adequate  availability  of  facility  resources.  Inadequate  facility  resources  will  seriously 
impact  the  Year  2000  risk.  Twenty  three  systems  reported  poor  to  moderate  availability  of 
personnel  resources.  This  will  increase  the  overall  Year  2000  risk  for  these  systems. 

This  data  indicates  that  the  SPAWAR  systems  are  impacted  by  the  same  Year  2000 
problems  that  private  industry  has  been.  In  addition  to  these  cost  drivers,  DOD  systems  also  have  some 
unique  drivers  such  as  complex  interfaces  and  highly  integrated  systems. 

e.  SPA  WAR  Systems  Year  2000  Cost  Estimate 

Figure  7  shows  the  current  SPAWAR  Year  2000  cost  estimates  provided  to  the  DoN. 
Using  a  modified  DOD  model  for  cost  estimation  the  SPAWAR  organization  estimates  that  its  Year 
2000  impact  at  $130M.  This  estimate  did  not  include  those  systems  that  reported  they  had  no  Year 
2000  problem.  If  SPAWAR  had  followed  the  DOD  cost  estimation  model  and  just  determined  total 
lines  of  executable  code  for  all  systems  and  multiplied  this  value  times  the  appropriate  cost  factor,  they 
would  have  had  a  higher  Year  2000  cost.  Approximately  30%  of  the  SPAWAR  systems  reported  no 
Year  2000  problem.  So  a  rough  cost  estimate  would  have  been  30%  higher.  A  second  cost  estimate 
using  various  cost  estimating  models  produced  an  estimate  of  15M  to  resolve  SPAWAR  Year  2000 
problems.  The  wide  variance  in  the  cost  estimates  has  created  confusion  for  upper  management  trying 
to  get  a  handle  on  the  scope  of  this  problem. 

In  the  SPAWAR  case  study  it  was  apparent  that  a  more  refined  cost  estimate  was 
required  to  provide  meaningful  year  2000  cost  estimates  to  upper  management.  A  significant  problem 
with  trying  to  estimate  the  cost  of  a  year  2000  effort  is  that  cost  estimation  has  traditionally  relied  on 
historical  data  from  similar  projects  or  parametric  models  developed  to  account  for  the  various  cost 

factors  involved  in  a  development  effort.  As  discussed  in  Chapter  4,  year  2000  cost  estimation  has  a 
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number  of  unique  cost  factors  which  render  existing  parametric  models  less  applicable  than  they  are  for 
traditional  software  development  or  maintenance  efforts  and  historical  data  non-existent.  Although  the 
Year  2000  problem  is  similar  to  other  software  problems,  it  has  some  major  nuances  that  make  it  more 
than  a  standard  maintenance  problem.  The  DOD  has  initially  adopted  a  high  level  approach  ($1.10  x 
ELOC  for  AIS  and  $8.00  x  ELOC  for  Others)  to  estimating  the  Year  2000  costs.  While  this  approach 
has  forced  consistency  between  projects  and  across  organizations  and  provided  Congress  and 
management  a  high  level  look  at  the  impact  of  the  Year  2000  effort,  it  is  now  necessary  to  provide  a 
more  accurate  estimate  so  that  managers  can  more  accurately  plan  for  funding  and  resource  allocation. 

As  Emmet  Paige  (OSD/C3I)  stated  in  his  memo  of  14  January  1997,  “Once  a  rough  work  year 
estimate  has  been  obtained,  it  is  time  to  begin  an  in-depth  analysis  of  the  costs  associated  with 
solving  the  Year  2000  problem.” 
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ESTIMATING  THE  YEAR  2000  PROBLEM 

As  of  27  June  1997 


•  Other  Costing  Methods: 

•  PMs  using  existing 
cost  models 

•  160  Systems 

Total  Cost  =  $99  million 


•  Generic  Algorithm: 


•  AIS  =  $1.10  x  LOC 

•  Embedded  =  $8.00  x  LOC 

AIS  EMBEDDED 

LOC  35,414,229  11,454,832 

COST  $38,955,652  $91,638,653 

*Total  Cost  =  $130  million 


*does  not  include  LOC  for  55  systems  that  did  not  report  LOC,  this  is  ~l/3  of  the  systems  so  that 
value  could  be  significantly  higher  depending  on  the  LOC  of  these  systems 


Figure  7.  SPA  WAR  Year  2000  Cost  Estimate 
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Gross  budget  estimates,  based  on  lines  of  code,  suffice  as  a  way  to  gain  high  level  awareness,  but  if 
these  statistics  are  used  beyond  this  early  planning  phase  the  risk  of  measuring  the  project  against 
unrealistic  numbers  increases.  Actual  Year  2000  costs  must  evolve  through  the  various  phases  of  the 
effort.  In  the  SPAWAR  case  study  it  became  quite  apparent  that  the  current  costs  must  be  refined.  As 
shown  in  Figure  7,  the  estimated  year  2000  cost  ranges  from  130M  using  the  ELOC  method 
recommended  by  the  DOD  and  99M  using  other  methods. 

Bruce  Hall  of  the  Gartner  Group,  Inc.  testified  before  the  congressional  subcommittee  on  March 
20, 1997,  The  year  2000  project  can  be  likened  to  an  old  house  that  needs  remodeling.  We  know  it 
is  a  big  job  and  we  are  trying  to  figure  out  how  much  it  will  cost  and  how  long  it  will  take.  But,  we 
are  trying  to  predict  the  cost  of  the  job  while  standing  on  the  curb  across  the  street.  If  we  were  able 
to  walk  through  the  house,  our  estimate  would  be  more  accurate,  and  only  by  getting  in  and  actually 
doing  some  of  the  work  can  we  realistically  tell  what  we  are  up  against.  And,  as  usual.  The 
contractor  thinks  the  job  will  cost  more  than  the  homeowner  thinks  it  should. [Ref.  2] 

It  has  become  apparent  from  looking  at  the  data  collected  during  this  case  study  that  in  addition  to 
getting  off  the  curb  and  into  the  house  we  also  have  to  adapt  our  cost  estimation  methodology  to 
include  the  unique  aspects  of  remodeling  an  old,  a  vintage,  house,  AKA  the  Year  2000  effort. 

The  SPAWAR  systems  were  generally  assessed  without  the  use  of  automated  tools  to 
assist  in  their  Year  2000  assessments.  The  assessments  were  based  on  system  expert  analysis  and  in 
some  cases,  testing  by  turning  the  clock  ahead  to  Year  2000  and  observing  the  effect  on  the  system.  As 
outlined  in  Chapter  IV  there  are  a  number  of  unique  cost  drivers  that  will  impact  the  cost  of  Year  2000 
compliance.  The  DOD  has  devoted  a  significant  amount  of  time  attempting  to  determine  exactly  how 
much  the  year  2000  compliance  effort  will  cost.  Determining  the  exact  cost  of  a  year  2000  effort  will 
be  difficult  without  previous  data  or  models.  From  this  case  study  it  was  apparent  that  these  models 
must  take  into  account  these  unique  year  2000  cost  drivers.  One  approach  that  is  currently  in  the 
literature  that  would  provide  more  refined  costing  information  yet  not  devote  an  inordinate  amount  of 
time  to  estimating  Year  2000  cost  is  the  use  of  assessment  data  that  lists  the  instances  of  dates  in  a 
systems  code  combined  with  the  year  2000  unique  cost  factors  to  estimate  Year  2000  costs.  Using  this 
approach  a  manager  must: 

•  determine  the  executable  source  lines  of  code  (ELOC)  for  legacy  systems 

•  determine  the  size  of  s/w  databases 
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•  determine  the  incidence  of  date  references  in  applications 

•  determine  the  incidence  of  date  references  in  current  databases 

•  estimate  the  effort  to  repair  each  date  reference 

•  estimate  the  effort  to  test  and  validate  each  date  reference 

•  estimate  the  error  injection  rate 

•  estimate  tool  procurement  costs 

•  estimate  hardware  procurement  costs 

•  estimate  COTS  upgrade  procurement  costs 

•  estimate  infracture  repair/replacement  cost 

•  estimate  impact  on  interfaces  with  external  systems 

This  approach  will  help  refine  the  current  cost  estimates  that  currently  do  not  take  into 
account  the  amount  of  date  related  code  within  a  system  nor  the  year  2000  unique  cost  factors. 
Systems  that  do  not  deal  extensively  with  dates  would  have  a  proportionately  lower  cost  estimate  than 
systems  that  do.  As  I  indicated  determining  the  exact  cost  of  a  Year  2000  effort  will  be  extremely 
difficult  without  previous  data  or  models.  One  approach  would  be  to  use  a  methodology  similar  to  the 
one  cited  above,  calibrated  with  the  year  2000  cost  factors,  to  achieve  a  more  accurate  rough  estimate 
that  will  likely  err  on  the  high  side  than  get  on  with  the  effort  of  correcting  the  problem. 
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B.  SUMMARY 


The  Assessment  Phase  is  considered  one  of  the  most  critical  phases  of  a  year  2000  effort.  An 
important  aspect  of  the  SPAWAR  Year  2000  effort  that  was  brought  out  during  this  during  this  case 
study  is  the  large  amount  of  time  and  effort  required  during  the  assessment  phase  and  the  uncertainty  of 
the  data  collected.  It  is  therefore  critical  that  an  organization  attempt  to  streamline  this  phase  and 
ensure  that  the  information  collected  is  reliable  so  that  plans  and  resources  can  be  developed  and 
allocated  for  the  remainder  of  the  year  2000  effort.  The  Assessment  phase  is  one  of  the  unique  aspects 
of  a  Year  2000  effort  and  because  of  the  pervasive  and  insidious  nature  of  the  Year  2000  problem 
every  system  in  an  organizations  library  must  be  assessed  for  compliance.  The  following  are  the 
lessons  learned  during  the  SPAWAR  case  study. 

•  Strong  upper  level  management  support  and  monitoring  of  the  effort  is  critical.  As  with  any 
major  project,  strong  upper  level  management  support  is  essential  to  the  projects  success. 
This  is  especially  true  with  a  year  2000  effort  which  has  often  been  considered  to  be  more 
of  a  management  challenge  than  a  technical  one. 

•  Creation  of  Year  2000  Office  -  It  is  important  for  an  organization  to  create  a  year  2000 
project  office  and  team  as  soon  as  they  begin  their  year  2000  effort.  This  group  will  become 
the  year  2000  experts  in  the  organization  and  the  central  repository  for  all  year  2000  data 
and  information.  This  group  should  be  staffed  with  “top  performers”  within  the 
organization.  This  team  will  be  asked  to  provide  a  wide  variety  of  technical  services,  and 
the  better  they  are,  the  smaller  the  impact  will  be  on  project  personnel  and  the  smoother  this 
complicated  process  will  proceed.  Its  the  adage  “pay  now  or  pay  later”  unfortunately  there  is 
little  time  for  latter  when  addressing  the  Y2K  problem.  It  can  not  be  over  emphasized  that 
anything  you  can  do  to  expedite  this  process  and  reduce  duplication  of  effort  is  worth 
looking  into.  Some  of  the  tasks  this  group  will  need  to  initiate  immediately  are: 

•  establish  an  organization  year  2000  Web  page 

•  establish  a  year  2000  systems  reporting  database 

•  establish  year  2000  compliance  criteria 

•  determine  COTS  year  2000  compliance 
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•  determine  H/W  year  2000  compliance 

•  Year  2000  tools 

•  evaluate  tools 

•  coordinate  tool  procurement 

•  provide  tool  recommendations/training/support 

•  support  assessments 

•  establish  year  2000  test  cases  sample 

•  Reduce  duplication  of  effort  -  It  is  critical  that  duplication  of  effort  be  reduced  to  a 
minimum.  The  Y2K  team  should  be  the  center  for  all  Y2K  information.  The  better  this 
office  performs  the  more  you  can  minimize  the  impact  on  your  project  personnel.  If  each 
project  does  not  have  to  contact  vendors  to  determine  compliance,  evaluate  tools  etc.  it  is 
valuable  time  that  can  be  spent  on  other  efforts  or  in  resolving  the  year  2000  problem.  This 
approach  will  also  provide  consistency  throughout  the  organization. 

•  Initiate  Awareness  program  -  Initiate  a  year  2000  awareness  program  within  the 
organization.  This  should  involve  training  and  regular  status  and  information  updates. 

•  Systems  Inventory  -  Initiate  an  organization  wide  systems  inventory.  It  is  critical  that  all 
systems,  COTS,  GOTS,  etc.  are  identified  as  early  as  possible.  This  is  what  your  assessment 
will  be  based  on  and  without  an  accurate  accounting  of  the  systems  in  the  organization  the 
Assessment  phase  will  flounder.  The  earlier  this  effort  is  started  the  better.  As  was  observed 
in  the  SPAWAR  case  study  this  effort  can  take  an  inordinate  amount  of  time  if  allowed  to, 
and  will  impact  the  succeeding  phases. 

•  Year  2000  POA&M  -  Develop  a  year  2000  POA&M,  starting  from  the  back  and  working 
forward.  Determine  the  latest  date  you  can  complete  implementation  and  still  have 
sufficient  time  to  observe  the  systems  performance  in  an  operational  environment  and  still 
have  time  to  resolve  any  problems  found  prior  to  the  year  2000.  Then  work  forward  from 
that  date  allocating  time  for  each  of  the  respective  phases.  It  will  quickly  become  obvious 
that  you  will  not  have  excess  time  in  any  of  the  phases,  so  anything  you  can  do  to  expedite 
these  tasks  and  reduce  duplication  of  effort  the  more  time  you  will  have  to  deal  with  the 
problem.  The  plan  must  include  hard  dates  for  the  completion  of  each  phase  and 
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intermediate  reviews  to  expedite  these  efforts  and  identify  problems  early  on. 

Visibility  -  It  is  important  that  upper  management  give  this  issue  high  visibility,  with 
frequent  status  reviews  and  incentives.  The  organization  needs  to  realize  this  is  an  important 
issue  that  is  not  going  away.  The  year  2000  team  needs  to  maintain  year  2000  visibility 
through  the  Web  page,  email,  memo’s,  and  other  appropriate  media.  As  we  have  seen  in  our 
case  study  projects  tend  to  focus  on  the  immediate  task  at  hand  and  that  is  normally  the 
funded  one.  When  year  2000  reviews  are  scheduled  then  effort  will  shift  to  the  year  2000. 
This  level  of  effort  needs  to  be  maintained  if  the  year  2000  effort  is  to  be  successful,  though 
it  may  be  at  the  cost  of  other  priorities.  Upper  management  must  allow  relief  with  the  other 
tasking  if  the  expect  to  get  meaningful  support  for  the  year  2000  effort. 

Top  Priority  -  The  year  2000  problem  needs  to  be  made  a  top  priority  with  clear  direction  on 
priority  conflicts.  Upper  management  needs  to  establish  year  2000  as  one  of  its  top 
priorities  and  reinforce  this  throughout  the  organization. 

Funded  -  The  year  2000  effort  needs  to  be  a  funded  effort,  and  directed  as  separate  tasking. 
This  way  managers  can  allocate  resources  to  work  on  this  effort  and  not  have  to  borrow 
somebody  from  another  effort  every  time  they  receive  another  data  call.  The  initial 
approach  in  the  DON  has  been  to  add  it  to  the  current  tasking  without  additional  funding  or 
schedule  relief  for  the  other  work  being  done.  This  impacts  the  ability  of  projects  to 
dedicate  the  resources  this  problem  requires  to  provide  accurate  data  that  can  be  used  by 
upper  management  for  planning  and  resource  allocation. 

Cost  Estimation  -  The  final  product  of  the  Assessment  Phase  should  be  a  revised  year  2000 

cost  estimate.  Cost  estimation  for  Year  2000  is  sin  evolutionary  process.  The  initial  cost-per- 

line  of  code  estimates  were  sufficient  for  providing  general  estimates  during  the  early 

stages  of  the  budgeting  processes  but  are  not  sufficient  for  allocating  resources  and  refined 

budgeting  requirements.  Year  2000  cost  estimates  must  evolve  through  the  various  phases 

of  a  year  2000  effort  as  more  information  becomes  available.  During  the  Assessment  phase 

the  projects  will  have  completed  their  assessment  efforts  and  can  use  that  data  as  input  into 

a  parametric  or  other  cost  model  to  calculate  a  revised  year  2000  estimate.  From  the 

SPAWAR  case  study  it  was  found  that  the  parametric  cost  estimation  models  needed  to  be 

calibrated  to  take  into  account  the  unique  cost  factors  involved  in  a  year  2000  effort.  It  is 
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important  to  identify  the  cost  estimation  tools  and  methodology  to  be  used  throughout  each 
of  the  DOD  defined  phases  of  a  year  2000  effort.  This  is  important  so  that  the  appropriate 
data  can  be  collected  during  the  various  phases  for  input  into  the  cost  model.  If  the 
required  data  is  identified  early  on  it  is  usually  easier  to  collect  while  certain  activities  are 
going  on  rather  than  have  to  go  back  and  recreate  it  or  have  a  separate  effort  collect  the  data. 
It  is  also  very  important  that  whatever  cost  estimation  model  is  chosen  it  is  calibrated  using 
the  unique  year  2000  cost  factors  identified  in  Chapter  IV  of  this  case  study.  These  cost 
factors  should  be  evaluated  to  determine  their  application  to  an  organizations  particular  year 
2000  efforts. 
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APPENDIX  A 

YEAR  2000  COST  FACTORS  CHECKLIST 


Provided  by  Mr.  Bob  Molter,  ASD/C3I 

NOTE:  Year  2000  “compliancy”  includes  proper  processing  of  Leap  Years  [The  Year  2000  is  a  Leap 
Year] 

Application  Software: 

_  Size:  Number  of  executable  lines  of  code  (LOC) 

_  Age:  Older  code  tends  to  be  less  structured  and  thus  harder  to  understand 

_  Complexity:  Relative  intricateness/understandability  of  the  business  rules 

_  Documentation:  Degree  of  documentation  available  and  its  understandability 

_  Programmer:  Familiarity  with  the  program  code.  Level  of  skill/competency/expertise 

_  Source  Code:  Availability 

_  Date-  “Intensiveness”:  Relative  number  of  date  related  calculations/comparisons 

_  Embedded  Dates:  Frequency  of  date  use  as  part  of  data  element  or  in  data  element  codes 

_  Date  Formats  Used:  Consistency  within  the  system  of  a  standard  date  format 

_  Year  2000  Strategy  (Field  expansion/procedural  code/sliding  window):  Different  strategies  to 

achieve  Year  2000  “compliancy”  have  different  costs 

_  Language:  Some  languages  (e.g.,  COBOL  68)  are  unable  to  properly  process  the  Year  2000  so 

the  software  will  have  to  be  upgraded/changed.  Additionally,  the  language  relates  to  the  availability  of 
the  Year  2000  COTS  tools,  programmers  to  work  on  the  system,  and  availability  of  Year  2000 
compliant  COTS] 

Hardware/System  Software:  Year  2000  compliancy  of  each  of  the  components  of  the  technical 
environment  is  required.  [Often  only  a  current  version  of  a  product  will  be  Year  2000  compliant.] 

_  Operating  System 
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-  Major  Subsystems:  Sometimes  subsystems  have  different  technical  environment  components 

_  Database  Management  System  (DBMS) 

_  Compilers/cross-assemblers  (available  --  sometimes  they  don’t  exist) 

_  Teleprocessing  (TP)  monitors 

-  Homegrown/locally  developed  software  that  is  used  in  conjunction  with  the  system 

_  Workstation  Software:  Consider  the  quantity  needed 

-  Workstation  BIOS  (handles  the  “system  clock  function”):  60-80%  of  PC  BIOSs  are  not  Year 

2000  compliant  —  most  are  soldered  to  the  motherboard,  some  are  re-programmable,  some  are 
“socketed”  and  some  can  be  replaced 

-  Programmer:  Familiarity  with  the  hardware  and  operating  system.  Level  of 

skill/competency/expertise 

-  Programmer  System  Software  (utilities  and  development  tools):  To  support  making  changes  to 

the  software 

-  Capacity/Usage  Level:  Making  a  system  Year  2000  compliant  may  increase  storage  (DASD) 

requirements  or  even  CPU  requirements  and  cause  a  need  to  purchase  a  larger  computer  or  more 
DASD 

-  Embedded  Software  (microchips/circuit  cards;  e.g.,  PABXs,  security  system  (access  control), 

cash  registers):  They  may  be  directly  or  indirectly  related  to  a  system,  and  may  not  be  Year  2000 
compliant.  The  availability  of  compliant  hardware  or  the  cost  of  developing,  and  the  quantity  required 
must  be  considered 

-  Communications:  Telecommunications  hardware  and  software  upon  which  the  system  depends 

must  be  considered 

-  Network  Timestamps  (LAN/W AN  network  clock  time):  Upon  which  the  system  is  dependent 

Database/Files: 

_  Number  of  date-related  data  elements 

_  Amount  of  available  DASD 

Year  2000  Tool  Support: 

-  Availability:  Many  languages  and/or  technical  environments  do  not  have  Year  2000  COTS  tools 

so  tools  must  be  developed  in-house  or  specifically  contracted  for  development 
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_  Quality 

External  Interfaces/Middleware: 

_  Data  Sources:  Must  be  evaluated  and  “bridges”  planned  as  required 

_  Data  Outputs:  Must  be  evaluated  and  “bridges”  planned  as  required 

_  EDI  Transaction  Sets:  System  may  generate  some  EDI  transactions  or  get  input  from  EDI 

transactions  which  require  “bridges” 

_  Reports:  Systems  may  generate  paper  reports  which  need  to  be  modified 

_  Screens:  Systems  may  have  screens  used  by  users  which  require  modification 

System  Plans: 

_  Planned  Major  Upgrade:  May  be  used  to  do  Year  2000  compliance  work  at  the  same  time  to 

reduce  costs 

_  Termination:  System  may  be  eliminated  before  a  Year  2000  problem  occurs 

_  Replacement:  System  is  planned  for  COTS  replacement  or  re-engineering  before  impacted  by  the 

Year  2000 

Miscellaneous  System-Related  Information: 

_  Sort  Routine  Year  2000  compliancy 

_  Backup  Routine  Year  2000  compliancy 

_  Archival  Routine  Year  2000  compliancy 

_  System  Criticality/Priority:  Really  not  required  for  cost  estimate,  but  a  good  time  to  record  this 

critical  planning  information 

_  Risk  Analysis  (if  system  fails):  Really  not  required  for  cost  estimate,  but  a  good  time  to  record 

this  critical  planning  information.  Consequences  of  system  failure  must  be  considered 
_  Risk  Analysis  (if  system  is  not  made  Year  2000  compliant ):  Many  systems  only  have  a  small 

“window  of  vulnerability”  during  which  not  being  able  to  process  Year  2000  properly  occurs. 
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Consideration  must  be  given  to  whether  or  not  this  “window”  is  acceptable;  i.e.,  the  system  won’t  be 
used  during  that  period,  or  a  “workaround”  will  be  established  for  that  period;  e.g.,  manual  processing. 
_  Contingency  and  Continuity  of  Operations  Planning 

Year  2000  Management: 

_  Project  Management 

_  Configuration  Management 

_  Change  Management 

_  Contract(or)  Management 

_  Year  2000  Emergency  Reaction  Team 

Year  2000  Testing: 

_  Establishing  Test  Environment 

_  Unit  Testing 

_  Integrated  Testing 

-  Year  2000  Simulation  Testing:  Can  sometimes  require  mirror  of  production  environment.  Might 

not  be  possible  until  technical  environment  is  made  Year  2000  compliant. 
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APPENDIX  B 


SPA  WAR  SYSTEM  INVENTORY  FORM 
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APPENDIX  C 

YEAR  2000  ASSESSMENT  CHECKLIST 


ASN(RD&A)  defines  “Year  2000  Compliance”  as  fault-free  performance  in  the  processing  of 
data  and  date-related  data  (including  but  not  limited  to  calculating,  comparing,  and  sequencing)  by  all 
hardware  and  software  products,  individually  and  in  combination.  Fault-free  performance  must  include 
the  manipulation  of  data  when  dates  are  in  the  20th  or  21st  century  and  must  be  transparent  to  the  user. 
Each  system  must  be  examined  individually  for  its  processing  of  dates.  The  following  is  a  brief 
checklist  of  issues,  problems  already  encountered,  and  reminders  to  assist  system  development  and 
maintenance  personnel  in  the  assessment  of  Y2K  compliance.  This  list  is  not  all-inclusive,  it  is  intended 
as  a  “thought  provoker.”  YES  answers  are  potential  problems  requiring  further  investigation  on  your 
part. 

YES  NO  Does  this  apply  to  your  system? 

_  _  1.  Use  of  2-digit  years  vice  4-digit  years  for  inputs,  messages,  internal  processing, 

data  storage,  and  /or  outputs.  (Consider  date  manipulation  during  comparisons, 
calculations,  sorting,  and  use  of  file  system/tape  system  tags) 

_  _  2.  Input  of  2-digit  date  fields  in  user/operator  entries,  scripts,  schedules  of  events,  or 

Startup  dates,  and  performance  of  date  validation  checks 

_  _  3.  Rejection  of  inputs  with  dates  of  ‘00  (meteorological  systems  had  this  problem) 

_  _  4.  Date  comparisons  made  without  date  validation  checks,  e.  g..  If  current  time  is 

less  than  previous  time,  is  the  data  ignored? 

_  _  5.  Processing  of  time  periods  greater  that  100  years,  or  across  year  2000  boundary. 

(Airline  and  telephone  systems  have  this  problem) 

_  _  6.  Checks  for  valid  date  ranges,  including  restrictions  due  to  overflows 

_  _  7.  Sorting  of  messages  or  files  so  that  year  ‘00,  ‘01,  etc.  incorrectly  sort  BEFORE 

‘99  (Could  affect  budgets,  schedules,  and  projections  beyond  2000) 
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8. 


Retrieval  or  deletion  messages  with  dates  beyond  1999,  or  with  dates  before  2000 
after  01/01/2000.  (Air  Force  systems  had  this  problem) 

9.  Records  such  as  clearances,  visit  requests,  and  licenses  with  expiration  dates 
beyond  2000  improperly  processed  or  rejected  as  “expired.”  (Mastercard  and 
security  systems  have  this  problem) 

10.  Use  of  special  values  (magic  numbers)  in  date  fields,  such  as  “00”,  “0/00/00”, 

“1/1 1/1 1”,  “99”,  “98”,  or  “9/9/99.”  (Could  represent  end-of-file,  no  data,  or  other 
special  flags  unrelated  to  the  system’s  mission) 

11.  Use  of  hard  coded  “19”,  “98”,  “99”,  “00”  in  the  formulas  for  dates 

12.  Use  of  12/31/99  expiration  date  as  “save  to  infinity”  -  causing  records  to  be  erased 
in  2000 

13.  Interpretation  of  new  inventory  records  with  expiration  dates  in  ‘00  as  “too  old,” 
resulting  in  inventories  being  discarded  or  rejected.  (Blood  banks  and  inventory 
systems  have  this  problem) 

14.  Incorrect  calculation  of  time  duration  across  01/01/2000,  affecting  tracking 
programs,  time  elapsed  calculations,  and  aging  calculations 

15.  Date  formats  stored  internally  using  an  unconventional  base  date  with  an  offset  of 
the  number  of  seconds/minutes/  hours/days/weeks  since  that  base  date.  (GPS  has 
this  problem) 

16.  Register  overflow  during  date  calculations  of  base  dates  plus  offsets.  (Consider 
the  size  of  the  data  type  that  is  used  to  store  the  offset:  8-bit,  16-bit,  32-bit,  64-bit, 
other) 
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YES  NO  Does  this  apply  to  your  system? 


17.  Failure  to  calculate  for  Leap  Years  using  all  three  required  rules: 

•  If  the  year  is  divisible  by  4,  it  is  a  leap  year,  UNLESS 

•  The  year  is  also  divisible  by  100,  then  it’s  not  a  leap  year,  UNLESS 

•  The  year  is  also  divisible  by  400,  then  it  is  a  leap  year 

(So  2000  is  a  leap  year,  1900  and  2100  are  not.  JTIDS  and  USAF  Airborne  C&C 
systems  calculate  this  incorrectly) 

18.  Importing  date  data  from,  or  exporting  to,  other  applications  and/or  systems  using 
Leap  year,  2  digit  dates,  and  dates  after  2000 

19.  Use  of  COTS  products  that  rely  on  the  date  for  licensing,  that  could  prematurely 
“expire”  on  01/01/2000 

20.  Use  of  older  versions  of  ORACLE  and  ORACLE-DBMS  that  do  not  have  newer 
roll-over  “rr-data”  type 

2 1 .  Use  of  these  date  milestones  in  your  system: 


_ 

1995-10-01 

Plans  for  5  Fiscal  Years  or  more  extend  to  FY2000 

1996-01-01 

overflows  Unisys  mainframe 

1996-01-01 

Four-year  plans  (budgets,  op  plans,  strategies)  end  in  2000 

1996- Autumn 

“Class  of  2000”  enters  academies  and  colleges 

1996-10-01 

Plans  for  4  Fiscal  Years  or  more  extend  to  FY2000 

— 

1997-01-01 

Three-year  plans  extend  to  2000 

1998-01-01 

Two-year  plans  extend  to  2000 

1999-08-22 

GPS  rolls  back  to  1980-01-06  (uses  1024- week  cycle) 

— 

1999-09-09 

9/9/99  flag  for  record  deletion 

— 

1999-10-01 

Government’s  FY2000  begins 

— 

2000-01-01 

overflows  2-digit  years 

2000-01-10 

first  9-character  date 
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2000-10-10 


first  10-character  date 


2000- 02-29 

2001- 01-01 
2001-10-03 
2019-12-31 
2029-12-31 
2034-01-01 
2036-12-31 
2049-12-31 


Leap  Year(1900  was  not)  (JTIDS  tables  are  incorrect) 

Twenty  First  Century  (not  2000) 

overflows  Tandem  systems 

yy-date  limit  of  Microsoft  Excel  95 

yy-date  limit  of  Microsoft  Excel  (next  major  version) 

Share/43  rolls  back  to  1970 

date  limit  of  Visual  C++  (4.x)  runtime  library 

date  limit  of  Microsoft  Project  95  and  previous  versions 


22.  Failure  of  the  “Rollover  Test,”  where  the  system’s  date  is  set  to  12/31/1999,  the 
system  turned  off  to  allow  roll  over  of  century,  then  turned  back  on  to  check  dates 
(See  sample  instructions  for  PCs  and  Macintoshes  on  Internet  at 
http://infosphere.safb.af.mil/~jwid/fadl/valida.htm  Other  tests  can  be  tailored.) 

23.  Use  of  proportional-character  printer  forms  or  terminal  screens  which  may 
overflow  or  line-wrap  with  a  20xx  year  instead  of  a  19xx  year 

24.  Interface  with  the  Global  Positioning  System  (GPS),  whose  1024-week  calendar 
rolls  back  to  1980  on  August  22,  1999 

25.  Dates  are  stored  using  unconventional  data  names,  or  names  “overlaid”  or 
“equated”  to  your  data  names  of  year,  yr,  date,  century,  time,  mmddyy, 
mmddyyyy,  ddmmyy,  ddmmyyyy,  yyddd,  yyyydd,  clock,  time_in,  time_out,  sent, 
received,  age,  purge,  expire,  nineteen,  twenty,  elapsed;  or  combinations  of  these 
and  other  terms  such  as  xxx_year,  year_xxx,  etc. 
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APPENDIX  D.  SPAWAR  STATUS  REPORTS 


A  summary  of  the  SPAWAR  Y2K  status  as  of  Friday,  25  July: 

1.  Numerous  changes  were  made  this  period.  Two  systems  have  been  deleted 
(two  CUDIXS  entries  were  merged;  IPGPS/EPLGR  is  assigned  to  JPO).  Two 
checklists,  seven  inventory  forms,  and  several  updates  were  received.  Of 

the  160  systems,  158  are  now  in  DIST  with  at  least  basic  information.  Of 
the  two  remaining,  we  don’t  have  enough  info  to  enter  GVRC,  and  ECIM  is 
being  terminated. 

2.  We  are  tracking  160  SPAWAR  systems.  We  are  also  negotiating  about 
several  other  possible  systems  with  NAVMASSO  and  SPAWAR  07. 

-  Inventory  forms  have  been  received  for  144. 

-  Signed  checklists  have  been  received  for  127. 

-  DIST  entries  have  been  made  for  158. 

3.  18  systems  still  have  “J”  status  -  internal  assessment  not  complete.  The 
target  completion  date  for  the  Assessment  Phase  was  30  June.  These 
unassessed  systems  are: 

NRaD:  FVLF  SSPA,  SST 

PMW176:  JMINIDAMA  SAC,  SSIXS-SMART,  PORTABLES,  SRC-54  SINCGARS, 
HAFB,ARQ-53  SINCGARS,  MCIXS 
PMW181:  ZEUS 
PMW185:  GFO 

PMW1 87:  GVRC,  6  parts  of  NAVSSI 

4.  By  the  way,  on  the  SPAWAR  webpage  at 

http://www.nosc.mil/spawar/programs/  there  are  162  “Programs,  Products,  and 
Services”  listed  by  PMW.  Only  42  of  these  are  in  our  systems  inventory  - 
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others  include  hardware,  studies,  etc.  But  many  sound  like  software  systems 
to  me:  Automated  Surface  Observing  System,  Defense  Message  System,  MATCALS, 
NSIPS,  SMOOS,  WWMCCS/GCCS  -  are  all  these  systems  or  their 
replacements/components  covered  in  our  Y2K  inventory?  One  of  our  major 
tracking  problems  is  defining  system  names  and  system  boundaries. 

5.  Pilot  system  assessments  are  being  conducted  by  MITRE  on  NAVMACS  II  and 
NAVSSI.  4  to  8  weeks  effort  remain. 

Assess  Signed  Inventory 
Total  -ment  Chlists  Forms 
Systems  Needed  Needed  Needed  POC 


NRaD 

2 

2 

2 

2 

Singer 

PD13 

3 

0 

0 

0 

Colket 

(Complete!) 

PMW-151 

27 

0 

6 

1 

Howard,  Rieken 

PMW-152 

9 

0 

0 

0 

DeGraff,Rieken  (Complete!) 

PMW-161 

2 

0 

0 

0 

Grant 

(Complete!) 

PMW-162 

2 

0 

0 

0 

Grant 

(Complete!) 

PMW-163 

11 

0 

0 

0 

Grant 

(Complete!) 

PMW-171 

5 

0 

0 

0 

Magno,  Jih 

(Complete!) 

PMW-173 

15 

0 

0 

0 

Jensen,  Jih 

(Complete!) 

PMW-176 

49 

7 

20 

6 

Jih 

PMW-181 

3 

1 

1 

1 

Cockerill 

PMW-182 

2 

0 

0 

0 

Cockerill 

(Complete!) 

PMW-183 

1 

0 

0 

0 

Cockerill 

(Complete!) 

PMW-185 

3 

1 

0 

1 

Cockerill 

PMW-187 

16 

7 

2 

2 

Cockerill 

PEO-SCS 

8 

0 

0 

1 

Pollack 

SPAWAR  05/07  3 

0 

2 

2 

Anderson/Hamaguchi 

Totals 

160 

18  33 

16 
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i  STATUS  (by  organizat 
As  of  25  July  1997 

(In  Number  of  Systems) 


APPENDIX  E.  SPA  WAR  SYSTEM  INVENTORY  RESULTS 
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SPAWAR  SYSTEM  INVENTORY 
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SPAWAR  SYSTEM  INVENTORY  AS  OF  JULY  25,1997 
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B8  Compiler  Availability  Is  the  compiler/assembler  available?  (yes/no)  YES:  108  NO:  9 
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F9  Tool  Availability  Are  Programmer/System  software  utilities  and  YES:  42  NO:  8 

development  tools  available  to  support  software  changes 
(ves/no) 

F10  Application  Expertise  RED:  low  programmer  familiarity  with  application;  RED:  1  YELLOW:  10 

YELLOW:  medium  familiarity;  GREEN:  high  familiarity  GREEN:  47 
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